4                                 Autentizace uživatele a autorizace dat

V kapitole o aplikačních protokolech jsme poznali, že tyto dnes již klasické aplikační protokoly se primárně orientují na autentizaci pomocí jména a hesla. Mnohé z těchto protokolů jsou připraveny na sofistikovanější mechanismy autentizace. Např. protokol IMAP4 má pro tyto účely připraven příkaz AUTHENTICATE (obdobně jsou na tom protokoly HTTP a POP3).

 

Autentizace uživatele je možné provést na základě:

 

Snaha je jednotlivé uvedené metody kombinovat.

4.1                           Hesla

Heslo, které se používá vícenásobně, asi všichni znají. Již asi méně známé je, že  přístupové heslo na straně serveru nebývá uchováváno v čisté textové podobě, ale znehodnocené jednocestnou funkcí proti zneužití správcem systému.

4.2                           Jednorázová hesla

Jednorázová hesla řeší problém odposlechu hesla během jeho přenosu sítí a následným použitím odposlechnutého hesla. Jednorázová hesla se nepoužívají pouze u aplikací provozovaných v počítačových sítích, ale i u tak odlišných aplikací jako je CallCentrum, kdy je nutné autentizovat uživatele, který požaduje služby běžným telefonem.

 

Jak je to vlastně možné, že uživatel může pokaždé zadat jiné heslo? Algoritmů na tvorbu jednorázových hesel je celá řada.

4.2.1                     Seznam jednorázových hesel

Nejjednodušší metodou jednorázových hesel je seznam jednorázových hesel. V tomto případě, je vygenerován seznam hesel, který může být vytištěn na papír a předán uživateli (resp. zaslán uživateli bezpečnou elektronickou poštou). Stejný seznam existuje i na straně systému, kde mohou být i jednotlivá jednorázová hesla znehodnocena jednocestnou funkcí.

 

Jinou možností používání jednorázových hesel je jednotlivá hesla očíslovat a nevyžadovat hesla jedno po druhém, ale náhodně. Náhodný výběr hesel může být i s opakováním, tj. pak se v podstatě nejedná o „jednorázové heslo“, ale požadavek na výběr dvou stejných hesel v pro útočníka zajímavém čase je málo pravděpodobný.

 

Pro některé aplikace je dostatečná i autentizační karta. Jedná se o plastikovou kartičku  bez magnetického proužku a bez čipu s několika předtištěnými sadami čísel. 

 

 


 


Obr. 4-1 Autentizační karta

Princip použití spočívá v tom, že aplikace vygeneruje dotaz na zadání několika náhodně vybraných čísel vytištěných na kartě. Např. v podobě "zadejte třetí čtveřici čísel ze čtvrté sady vytištěných na Vaší Autentizační kartě".

 

Autentizační  karta je forma použití vícenásobných hesel s jednoduchým doplňkem vzdáleně připomínajícím heslo na jedno použití.

 

Výhodou tohoto prostředku jsou jeho zanedbatelné pořizovací náklady, kterými jsou získány velmi zajímavé bezpečnostní vlastnosti.

Obr. 4-2. Zadání jednorázového hesla pomocí autentizační karty

 

4.2.2                     Rekurentní algoritmus

 

Rekurentní algoritmus používá některý z algoritmů pro výpočet kontrolního součtu. Zvolme si jeden z těchto jednocestných algoritmů a označme jej F.  Dále si uživatel musí sám zvolit nějaký řetězec násada. Tento řetězec uživatel nikomu nesděluje – je to uživatelovo tajemství.

 

Kontrolní součet z řetězce násada  vyjádříme jako:

 

     F(násada).

 

Použijeme-li algoritmus F dvakrát opakovaně na tutéž zprávu, tj. F(F(násada)), pak budeme psát:

 

     F2(násada)

 

a obdobně

 

     Fn(násada)

 

bude znamenat, že jsme použili algoritmus F na řetězec násada celkem n-krát.

 

Použití této metody spočívá též nejprve v inicializačním kroku. Uživatel si pořídí  text násada (případně si jej zašifruje pomocí PINu).

 

V inicializačním kroku se uživatel a správce aplikace dohodnou na čísle, např. 1000. Uživatel vyrobí:

 

F1000(násada) a předá jej správci aplikace.

 

Správce aplikace si do databáze k našemu uživateli poznamená název algoritmu pro výpočet kontrolního součtu (tj. F),  číslo 1000 a F1000(násada). Správce tedy nezná  text násada (je to uživatelovo tajemství).

 

Při autentizaci pošle uživatel na server jméno, server ve své databázi zjistí, jakou uživatel používá autentizační metodu. Obratem server uživateli pošle dotaz obsahující  číslo (n-1),  tj. nyní 999. Uživatel vygeneruje odpověď F999(násada) a odešle to jako jednorázové heslo serveru.

 

Server  prověří totožnost uživatele, takže provede porovnání

 

F(F999(násada)) = F1000(násada)

 

Algoritmus F je mu znám a F1000(násada) má uloženo v konfiguračním souboru a F999(násada) obdržel v odpovědi uživatele.

 

Po úspěšném prověření uživatele uloží server do konfiguračního souboru místo hodnoty F1000(násada) hodnotu F999(násada) a místo čísla 1000 číslo 999. Při další autentizaci se vše provádí s číslem o jedničku nižším, tj. provádí se autentizace:

 

F(F998(násada)) = F999(násada)

 

Uživatel mohl tedy vygenerovat celkem 999 hesel na jedno použití, pak musí změnit hodnotu řetězce násada a správci serveru předat nový F1000(násada).

 

Ještě bychom se měli vrátit k procesu, kdy uživatel předává správci aplikace číslo n a hodnotu Fn(násada). Tyto údaje sice může předat osobně, ale to není příliš praktické. Uživatel totiž pravděpodobně nepřijde do styku se správcem aplikace, ale s obchodním útvarem provozovatele aplikace. V případě, že by autentizační údaje procházely mnoha rukama, tak je nebezpečí zneužití těchto údajů. Jednodušší je, aby obchodní útvary předaly klientovi jednorázové heslo (např. v zalepené obálce) a uživatel se při první autentizaci prokázal tímto jednorázovým heslem a přitom předal aplikaci i číslo n a hodnotu Fn(násada). Obdobně může dojít i k reinicializaci po dosažení n=1.

 

4.2.3                     S/KEY

Algoritmus S/KEY je implementací rekurentního algoritmu. S/KEY  je  popsán v RFC-1760. Jádrem je použití algoritmu pro výpočet kontrolního součtu MD4 (MD4 je popsán v RFC-1320).

 

Násadu si klient volí sám tak, aby byla dlouhá minimálně 8 bajtů.  

 

Algoritmus MD4 produkuje 16 bajtů dlouhý kontrolní součet. Ten se v tomto případě dělí na dvě poloviny po 8 bajtech, které se spojí operací XOR do výsledných osmi bajtů. Použijeme-li terminologii z předchozího paragrafu, pak algoritmem F je algoritmus MD4, jehož výsledek se dělí na dvě poloviny, které jsou operací XOR sloučeny do výsledných osmi bajtů.

 

S/KEY má nápadité rozšíření umožňující použít stejný algoritmus (včetně stejné násady) pro více aplikací (např. pro více serverů).  Princip spočívá v tom, že aplikace (server) vyzývající uživatele k prokázání své totožnosti (k autentizaci) klientovi zobrazí tři údaje:

 

Uživatel nejprve spojí násadu se solí a výsledný řetězec teprve použije jako násadu pro algoritmus F.

 

4.2.4                     OTP (One Time Password)

OTP je popsáno v RFC-1938, které rozšiřuje mechanismus S/KEY o možnost použití dalších algoritmů pro výpočet kontrolního součtu, jako jsou např. algoritmy MD5 (popsaný v RFC-1321) a SHA-1.

 

Server svou výzvu klientovi formuluje ve tvaru:

otp-algoritmus n sůl

Např.:

otp-md5 599 2f3a34

 

4.2.5                     Autorizace dat

Při autentizaci se prokazuje totožnost. Mnohdy je však třeba ověřovat pravost předávaných dat. Ověřování pravosti má dva aspekty:

  1. Ochrana před útočníkem, který data mění na cestě od odesilatele k příjemci.
  2. Ochrana příjemce před popřením pravosti odeslaných dat odesilatelem. Tuto ochranu je schopen zajistit pouze digitální podpis, kterým se budeme zabývat v následujících kapitolách.

 

První jednodušší případ autorizace dat (ochrana před útočníkem) je možné zajistit i jednoduššími prostředky než je digitální podpis. Digitální podpis není vždy vhodné nebo možné použít.

 

Pro takovouto autorizaci přenášených dat se opět používá některý z algoritmů pro výpočet kontrolního součtu. Odesílatel a příjemce se předem dohodnou na nějakém řetězci, který zají pouze oni – na sdíleném tajemství.

 

Přenášená data se rozdělí do bloků. Každý přenášený blok se doplní o kontrolní součet, který je počítán z přenášeného bloku dat a sdíleného tajemství. Jak se konkrétně tento kontrolní součet počítá, to závisí na konkrétní normě. Příkladem takové normy je např. RFC-2104 (HMAC: Keyed-Hashing for Message Authentication). Jinými příklady jsou protokoly SSL a TLS, kterým je věnována samostatná kapitola.

 

Sdílené tajemství je sdíleno mezi odesilatelem a příjemcem (nikdo jiný jej nezná). Sdílené tajemství je cosi podobného jako je symetrický šifrovací klíč, nepoužívá se  k šifrování, ale spojuje se s přenášeným blokem dat, aby se z toho výsledku spojení spočetl kontrolní součet.

 

Kdyby útočník chtěl změnit blok přenášených dat, pak by musel dopočítat i kontrolní součet, ten ale není schopen spočíst, protože nezná sdílené tajemství.

 

4.2.6                     Autentizační kalkulátory

 

Autentizační kalkulátory jsou elektronické pomůcky pro autentizaci klienta (případně pro autorizaci dat zadaných uživatelem). Autentizační kalkulátory zpravidla umí některý z kvalitních algoritmů pro kontrolní součet (např. MD5, SHA-1 apod.).

 

Uživatel obdrží od správce aplikace autentizační kalkulátor, avšak před tím je třeba autentizační kalkulátor připravit (tj. je třeba provádět management autentizačních kalkulátorů).

 

Příprava spočívá v tom, že do kalkulátoru se vloží tajemství, které je nazýváno násada. Tajemství je řetězec, který bude uložen v kalkulátoru na serveru aplikace (nikdo jiný toto sdílené tajemství mezi klientem a aplikací nezná). V databázi na serveru musí tak být pro každého uživatele udržována informace obsahující mj. sdílené tajemství. Před předáním kalkulátoru klientovi musí někdo tajemství do kalkulátoru naplnit. Dále je třeba ošetřit ztráty kalkulátorů a recyklaci kalkulátorů v případě vrácení kalkulátoru ošetřit jeho recyklaci (mj. vymazání tajemství).

 

V případě, že je použit symetrický šifrovací algoritmus, pak toto tajemství se použije jako šifrovací klíč.

 

Rozlišujeme tak kalkulátory:

?         Určené pouze pro autentizaci klienta.

?         Určené též pro autorizaci dat zadávaných uživatelem.

 

Uvedli jsme, že kalkulátory využívají jednocestné funkce – např. funkce pro výpočet kontrolních součtů apod. Detailní popis použitého algoritmus nebývá u autentizačních kalkulátorů  zveřejňován – výrobci kalkulátorů jej často považují za své vlastnictví. Dodavatel kalkulátorů zpravidla dodává nejen samotné kalkulátory, ale i software, který je volán aplikací v případě autentizace.

4.2.6.1               Kalkulátory určené pouze pro autentizaci klienta

Čas

 

Uživatelův autentizační kalkulátor obsahuje hodiny. Čas s přesností na minuty  (resp. poloviny minuty) je vstupem pro kalkulátor. Heslo na jedno použití se vytvoří jako kontrolní součet (např. algoritmem MD5) z času a sdíleného tajemství.

 

Pokud na serveru banky běží stejný čas, pak stejnou operaci je schopna provést i aplikace (tajemství je sdíleno mezi uživatelem a aplikací). Hodnotu získanou od klienta  server porovná s hodnotou spočítanou aplikací - pokud jsou obě stejné, pak je klientovi umožněn přístup.

 

Uživatelův autentizační kalkulátor může být dvojího provedení:

 

1.        Bez klávesnice. Pak se nepoužívá PIN. Heslo se každou minutu (resp. polovinu minuty) na displeji automaticky mění. (Typ bez klávesnice je oblíben zejména u top managementu pro svou primitivnost obsluhy). 

2.        S klávesnicí, aby bylo možné pořídit PIN. V tomto případě je sdílené tajemství v kalkulátoru uloženo zašifrováno PINem. Pro přístup k tajemství je tak nutné zadat PIN.

 

Otázkou je, co v případě, že oba řetězce nejsou shodné. Neshoda může být způsobena tím, že se hodiny kalkulátoru rozcházejí s hodinami v serveru aplikace. Server v takovém případě vypočítá některé hodnoty o několik minut vpřed i vzad a hledá, nedojde-li tam ke shodě. Dojde-li ke shodě např. s časem o 2 minuty zpět, pak uživateli též umožní přístup a do konfiguračního souboru si poznamená časový posun.

 

Challenge - Response

Server vygeneruje náhodný řetězec jako dotaz (Challenge). Klient tento náhodný řetězec spojí se sdíleným tajemstvím a z takto vytvořeného celku spočte kontrolní součet, který vrátí jako jednorázové heslo (Response) serveru. Jelikož server též zná sdílené tajemství, tak je schopen stejné jednorázové heslo též spočíst. Oba výsledky porovná a pokud jsou shodné, tak klientovi umožní přístup do aplikace.

 

Důležité je, aby se nezopakoval v krátkém časovém intervalu stejný dotaz. Je třeba použít kvalitní systém na generování dotazů (dotaz může být např. zřetězením času a náhodného čísla apod.).

 

Prakticky: klient zapne kalkulátor, zadá PIN, čímž si otevře přístup ke sdílenému tajemství. Aplikace klientovi zobrazí dotaz, klient jej pořídí na klávesnici kalkulátoru. Kalkulátor k dotazu připojí tajemství a spočte kontrolní součet - vytvoří jednorázové heslo. Klient opíše z displeje kalkulátoru heslo do okna aplikace a odešle jej na server.

 

Zjednodušeně lze říci, že podobný mechanismus se použije i při autentizaci klienta pomocí asymetrické kryptografie. Server vygeneruje náhodné číslo a klient vrátí digitální podpis tohoto čísla.

4.2.6.2               Kalkulátory umožňující i autorizaci příkazů

Kalkulátory určené pouze pro autentizaci počítaly kontrolní součet z času či náhodného čísla nebo použily rekurentní algoritmus.

 

V případě autorizace příkazu je nutné počítat kontrolní součet také z jednotlivých položek předávaných dat. Zpravidla se nepočítá kontrolní součet ze všech polí, ale pouze z těch nejdůležitějších. Která pole jsou ta nejdůležitější je věcí tvůrce aplikace.

 

Zatímco v případě autentizace klienta mechanismem Challenge - Response byl nucen klient pořídit na klávesnici kalkulátoru PIN a několikaciferný dotaz, tak při autorizaci příkazu je nutné pořídit na klávesnici kalkulátoru také jednotlivá pole příkazu (alespoň ta důležitá).

 

Prakticky: klient zapne kalkulátor, zadá PIN, čímž si otevře přístup ke sdílenému tajemství. Např. pomocí web-formuláře bude chtít zadat platební příkaz, pak kromě běžných polí platebního příkazu musí klient zadat i jednorázové heslo do dalšího pole. Klient pořídí platební příkaz do web-formuláře, ale nyní potřebuje vygenerovat jednorázové heslo, takže pořídí platební příkaz (určená důležitá pole příkazu) ještě jednou do autentizačního kalkulátoru. Kalkulátor zobrazí na displeji jednorázové heslo, které klient opíše do posledního nevyplněného pole web-formuláře a formulář odešle.

 

Významnou výhodou autentizačních kalkulátorů je jejich naprostá nezávislost na bezpečnosti prostředí. V tomto směru se jedná o zařízení, které má nesporné bezpečnostní přednosti. U některých klientů však není populární jednak nosit stále s sebou kalkulátor a jednak dvakrát pořizovat stejný příkaz.

 

Problém dvojího pořizování dat lze technicky řešit pomocí tzv. optického klíče. Uživatel pořídí data jednou na formulář na PC. Program na PC odvysílá pořízená data do autentizačního kalkulátoru, který spočte jednorázové heslo a zobrazí jej na displeji. Uživatel opíše jednorázové heslo z displeje kalkulátoru na PC. Otázka je jak PC odvysílá data do kalkulátoru. Optický klíč pracuje tak, že program na obrazovce PC otevře zvláštní okno, kde přenášenou informaci moduluje do zobrazování obrazců, které přijímá optický klíč. Jinou určitě bezpečnější cestou by bylo pořídit data na kalkulátoru a pomocí IR-portu je přenést do PC. 

 

4.2.7                     Jednorázová hesla přes GSM

Nevýhodou autentizačních kalkulátorů je samotná existence kalkulátoru, tj. z hlediska provozovatele aplikace se kalkulátor musí  pořídit, což není laciné, a z hlediska uživatele je zase nepříjemné, že se kalkulátor musí stále nosit s sebou a přitom je dobré jej nezničit či neztratit. Naopak mobilní telefon má dnes téměř každý a uživatelé jsou zvyklí jej s sebou nosit a starat se o něj a navíc si mobilní telefon pořizuje uživatel sám.

 

Že by mobilní telefon přímo nahradil autentizační kalkulátor je málo pravděpodobné. Nabízí se ale jiné použití. V okamžiku, kdy se klient má autentizovat, tak oznámí aplikaci své přihlašovací jméno. Aplikace vygeneruje jednorázové heslo a v databázi uživatelů najde číslo mého mobilního telefonu, na které pomocí SMS-zprávy jednorázové heslo zašle.

Obr. 4-4 Jednorázové heslo zasílané přes GSM

Tento způsob autorizace kombinuje dva nezávislé komunikační kanály. Tato skutečnost podstatným způsobem omezuje možnost zneužití, protože případný útok by musel být veden společně na oba nezávislé kanály, což je vysoce náročné. Další podstatnou výhodou jsou nízké pořizovací náklady a relativně jednoduchá obsluha. Jistým omezením tohoto řešení je, že klient musí být vybaven mobilním telefonem a že tento pracuje pouze v místě, kde má dostupný signál.

4.3                           Asymetrická kryptografie

Autentizace

Autentizace na základě asymetrické kryptografie je vždy nějakou variací na situaci znázorněnou na obr. 4-4. Představme si, že policista chce, aby mu občan prokázal svou totožnost na základě asymetrické kryptografie.

 

Zatímco v klasickém případě občan prokazuje svou totožnost na základě občanského průkazu, který předloží policistovi. Policista v klasickém občanském průkazu ověřuje totožnost na základě občanovy fotografie. Tak v elektronickém případě občan prokazuje svou totožnost na základě vlastnictví svého soukromého klíče. 

 

Princip prokazování totožnosti na základě asymetrické kryptografie je jednoduchý. Policista vygeneruje náhodné číslo č.  Toto číslo č  předá občanovi, který jej za pomoci svého soukromého klíče digitálně podepíše. Digitálně podepsané číslo č  předá občan policistovi, který provede verifikaci digitálního podpisu. 

 

Jak se provádí verifikace digitálního podpisu popíši v kapitole Certifikáty a certifikační autority (tato verifikace se provádí na základě veřejného klíče, který je obsažen v certifikátu – elektronické obdobě občanského průkazu).

 

Pro občana se tak základem stává ochrana jeho soukromého klíče. Odcizení soukromého klíče by způsobilo to, že zloděj by se mohl elektronicky prokazovat místo majitele soukromého klíče. Odcizení soukromého klíče lze přirovnat v případě klasických občanských průkazů k odcizení podoby z fotografie občanského průkazu.

 

Obr. 4-4. Autentizace za využití asymetrické kryptografie

 

Autorizace dat

Autorizace dat na základě asymetrické kryptografie se nazývá digitálním podpisem dat.

 

4.4                           Charakteristika prostředí

Z hlediska bezpečnostních charakteristik rozlišujeme následující tři typy prostředí, ve kterých jsou provozovány aplikace:

1.        Prostředí kontrolované provozovatelem aplikace – toto prostředí nemůže uživatel ani útočník ovlivnit, protože prostředí je předem nakonfigurováno a může do něj zasáhnout jen správce aplikace nebo výjimečně výrobce. Takovým prostředím je např. mobilní telefon či bankomat.

2.        Prostředí kontrolované klientem – klient sám si zodpovídá za konfiguraci a údržbu prostředí (např. osobní počítač na pracovišti či doma).

3.        Prostředí kontrolované třetí stranou –klient pracuje na PC, které je veřejně přístupné (např. v i-kavárně). Toto prostředí se vyznačuje tím, že za jeho bezpečnost nemůže odpovídat ani uživatel ani provozovatel aplikace. Takovýmto prostředím je např. internetová kavárna nebo školní počítačová učebna.

 

Otázkou je, jaké autentizační metody je možné v jednotlivých prostředích používat. Svůj názor jsem shrnul do následující tabulky:

 

 

Doporučuji v prostředí

Kontrolovaném provozovatelem aplikace

Kontrolované klientem

Kontrolovaném třetí stranou

Klasické heslo

Spíše ne

Ano, ale jen omezeně

Ne

Seznam hesel na jedno použití

Ano

Ano

Ano

Autentizační karta

Ano, ale jen omezeně

Ano, ale jen omezeně

Ano, ale jen omezeně

Jednorázová hesla přes GSM

Ano

Ano

Ano

Rekurentní algoritmy

(softwarová autentizace)

Ano

Ano

Ne, protože software na generaci odpovědi může být třetí stranou kompromitován

Autentizační kalkulátory

Ano

Ano

Ano

Soukromý klíč na disku

Ne

Ano

Ne

Hardwarové klíče s asymetrickou kryprografií

Ano

Ano

Ne

 

V případě, že doporučuji používat některé druhy hesel „jen omezeně“, pak mám na mysli skutečnost, že aplikace může pro méně nebezpečné akce požadovat heslo, ale pro náročnější akce může vyžadovat např. digitální podpis. Klasickým případem je elektronické bankovnictví, kde je možné pro zůstatek na účtu vyžadovat pouze heslo, ale elektronicky podaný platební příkaz musí být digitálně podepsán.

 

4.5                           Wrapper

V operačním systému typu UNIX se používá celá řada serverů: telnetd pro protokol TELNET, ftpd pro protokol FTP atd. Tyto servery se zpravidla nespouští trvale po startu systému. Po startu systému se spouští tzv. Superserver inetd, který očekává požadavky (naslouchá) na portech jednotlivých serverů. Přijde-li na nějaký port požadavek, pak pro vyřízení požadavku spustí příslušný server. Pro jaký port má spouštět jaký server má uvedeno na jednotlivých řádkách souboru /etc/inetd.conf.

 

 

Obr. 4-5 Superserver inetd

 Příklad řádku souboru /etc/inetd.conf pro spouštění serveru telnetd má tvar: 

...
telnet  stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd
...

Kde telnet specifikuje číslo portu podle souboru /etc/services, stream specifikuje typ socketu (stream nebo dgram), tcp specifikuje protokol podle souboru /etc/protocols, nowait určuje, že se nemá čekat na uvolnění socketu, root specifikuje uživatele, pod jehož UID se server spouští, a konečně následuje jméno programu (serveru) a parametry. Jako server se tedy spouští program /usr/sbin/telnetd.

 

Jako ochranu serverů spuštěných na našem počítači můžeme použít wrapper. Wrapper je program umožňující  ověření  klienta před tím, než bude spuštěn příslušný server. Původní wrapper byl napsán na Eindhoven University of Technology a autorem je Wietse Venema. Program se jmenuje tcpd. Dnes existuje více podobných programů a hovorově se označují jako wrappery. Např. wrappery spouštěné před programem sendmail ochraňují sendmail před některými útoky. Jiné wrappery spouštěné před některými servery mohou napravovat chyby těchto serverů atp.

 

Superserver inetd má ve svém konfiguračním souboru napsáno, pro jaký port má spouštět který server. Použije-li se wrapper, pak v témže konfiguračním souboru se místo jména serveru specifikuje wrapper a teprve parametrem wrapperu je název serveru.

 

Řádek souboru /etc/inetd.conf pro spouštění serveru telnetd má tvar: 

...
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd      telnetd
...

Nejprve je superserverem spouštěn wrapper (např. wrapper tcpd), který autentizuje klienta. V případě, že výsledek autentizace je kladný, tak je spuštěn příslušný server.

 

Obr. 4-6 Wrapper

Existují i superservery, které integrují činnost wrapperu a superserveru. Pak pochopitelně není třeba dvou po sobě volaných programů. Přínos wrapperu je ale právě v jednoduchosti jeho nasazení. V operačním systému typu UNIX není třeba žádných změn kromě přeložení wrapperu a jednoduché opravy souboru /etc/inetd.conf.

 

Na obrázku  4-6 jsem záměrně kromě programů telnetd uvedl program telnetxd. Program realizující proxy pro protokol TELNET se často jmenuje telnetxd. Proxy se z hlediska operačního systému i klienta jeví jako server, který podobně jako ostatní servery očekává požadavky na určeném portu.

 

Proxy je tedy také možné spouštět pomocí superserveru inetd. Před spuštěním proxy je také možné spouštět wrapper a provádět autentizaci klienta. Pomocí wrapperu je možné určovat, kdo může používat jakou proxy a kdo ne.

 

Použili-li jsme proxy k tomu, abychom umožnili klientům vnitřní sítě přístup do Internetu, pak wrapperem můžeme omezit přístup do Internetu jen pro vybrané uživatele. Ještě zajímavější je opačná úvaha. Co když vyjede náš zaměstnanec na služební cestu, tj. už není na vnitřní síti, ale v Internetu. Před ním není třeba chránit naše servery. A naopak jemu by se hodilo např. si vybrat poštu na serveru vnitřní sítě.

 

K ochraně vnitřní sítě se nabízí použít proxy v kombinaci s wrapperem. Na rozdíl od použití filtrace, oprávnění k průchodu proxy (oprávnění k použití proxy) nemusí záviset na tom, zda-li klient je z vnitřní sítě. Použít proxy může každý, kdo se autentizuje. Spustíme tedy proxy tak, aby skrze ni mohli klienti vnitřní sítě do Internetu a klienti Internetu na servery vnitřní sítě a ochranu provedeme wrapperem. Jenže s takovýmto rozhodnutím musíme být velice opatrní.

Rozdíl mezi jednoduchým wrapperem jako je program tcpd a wrappery používajícími např. heslo na jedno použití nebo asymetrické kryptografie je v činnosti klienta.

 

Program tcpd žádné další akce od klienta nepožadoval. Klienta si prověřil sám na základě jeho IP-adresy nebo identifikačním protokolem. Uživatel v případě, že byl kladně autentizován, tak ani nevěděl, že ve hře je nějaký wrapper. Pouze v případě, že jej wrapper odmítnul, tak o tom mohl přemýšlet, ale ničím nemohl do činnosti wrapperu zasáhnout - neměl k dispozici žádný příkaz. Výhodou takovéhoto transparentního řešení je skutečnost, že není třeba žádné programy upravovat ani učit uživatele nějaké nové autentizační dialogy.

 

V případě hesel na jedno použití wrapper s uživatelem komunikuje tzv. autentizačním dialogem. Vyšle uživateli (klientovi) autentizační dotaz a klient mu odpoví jednorázovým heslem. Wrapper si heslo zkontroluje a je-li správné, pak spustí příslušný server. Problém je tedy v tom, že uživatel se musí naučit autentizační dialog s wrapperem. To není na překážku např. pro řádkové klienty ftp a telnet. Ale už ftp realizované v oknech či klienti protokolu POP3 by museli být upraveni, aby vykonali tento dialog. Autentizační dialog lze i automatizovat, tj. uživatel není autentizačním dialogem zatěžován. Pro takový případ se používá např. čipová karta, avšak klienti musí umět využít čipovou kartu, tj. musí být rovněž upraveni. To vše činí autentizaci na aplikační úrovni u obecných protokolů velmi obtížnou. V mnoha případech se ukazuje výhodnější, když se zabezpečení posune na nižší úroveň, např. ve formě zabezpečení celého IP protokolu standardem IPSec.

4.5.1                     tcpd

Program tcpd je velice užitečným doplňkem našich serverů s operačním systémem UNIX. Umisťujete-li nějaký server na Internet a nepoužíváte jinou metodu autentizace klientů, pak určitě zvolte alespoň program tcpd.

Klient prokazuje svoji totožnost na základě své IP-adresy, případě jména svého počítače. Tj. v databázi programu tcpd jsou uvedeny IP-adresy nebo jména počítačů (případně skupin počítačů), jimž je přístup povolen. V případě, že je uvedeno jméno počítače, pak se vezme z příchozího IP-datagramu adresa odesilatele a provede se na ni reverzní překlad DNS. Takto získané jméno se porovnává s databází programu tcpd. Reverzní záznam DNS se dá ovšem podvrhnout snadněji než cokoli jiného, systém DNS na nic takového nepamatuje. Přestože autentizace na základě IP-adresy odesilatele není příliš dokonalá, je mnohem lepší než autentizace na základě DNS jmen a v některých případech může stačit. Např. jste-li nuceni používat TFTP-server, pak jste vděční i za takovouto autentizaci.

 

Konfigurační databáze se zpravidla skládá ze dvou souborů: /etc/hosts.allow a /etc/hosts.deny. V prvním souboru se specifikují počítače (případně jejich uživatelé), kteří mají přístup povolen, a v druhém ti, kteří mají přístup odepřen.

Soubory se interpretují po jednotlivých řádcích. Každý řádek má následující syntaxi: 

server : klienti [ : příkaz]

 

Jelikož program tcpd autentizuje klienty pro více serverů, tak se prvním parametrem identifikuje příslušný server. Např. telnetd, ftpd, rshd, rlogind ,... . Slovo ALL vyjadřuje všechny servery.

Druhým parametrem (klienti) specifikujeme klienty. Ke specifikaci se použije:

Posledním volitelným parametrem je příkaz systému UNIX, který se provede, jsou-li předchozí dva parametry kladně vyhodnoceny. Je zde také možné použít klíčová slova: allow (povolit) a deny (zakázat). Příklad řádku ze souboru /etc/hosts.allow:

 

telnetd,ftpd : info.pvt.net : allow

kterým povolujeme přístup protokolu Telnet a FTP z počítače info.pvt.net.

 

4.5.2                     Identifikační protokol

Kromě autentizace na základě IP-adresy odesilatele je možné autentizaci rozšířit o zpětné prověření uživatele na počítači klienta. Pro zpětné ověření se používá identifikační protokol specifikovaný v RFC-1413. Tento protokol se zpětně dotazuje počítače klienta, zdali nějaký jeho uživatel spojení požadoval. 

 

Je třeba upozornit na skutečnost, že z hlediska bezpečnosti je identifikační protokol velice primitivní a podvržení klienta v něm je triviální.

Obr. 4.7 Identifikační protokol

 

Na počítači klienta musí být spuštěn server pro zpětné ověřování. Wrapper při zpětném ověřování vystupuje v roli klienta. Identifikační protokol podle RFC-1413 používá zpravidla port 113.

 

Princip autentizačního protokolu snadno pochopíte na následující demonstraci. Instalujete-li na vašem serveru wrapper tcpd, pak si můžete ověřit, zda-li na klientském počítači běží server identifikačního protokolu.

 

Z klientského počítače provedete např. 

$ telnet  server.firma.cz

 

Na tomto počítači (klient.firma.cz) navazujete spojení s počítačem server.firma.cz. Abyste mohli navazovat spojení, musel vám být operačním systémem počítače klient.firma.cz přidělen port. Předpokládejme, že vám byl přidělen port 1500.

 

Spojení tedy navazuje počítač klient.firma.cz na portu 1500 se serverem server.firma.cz na portu 23/tcp (23/tcp je standardní port pro server telnet).

 

Nyní z počítače server.firma.cz můžete zpětně ověřit, zda-li nějaký uživatel počítače klient.firma.cz navazuje spojení. Pro ilustraci použijeme program telnet, kterým navážeme spojení na port 113/tcp (tj. na autentizační server.). Do vytvořeného TCP spoje se pak znakově vloží čísla portů serveru a klienta oddělená čárkou: 

 
$ telnet  klient.firma.cz   113
23,1500

 

Na portu 113 zpětně ověřujete, zda-li nějaký klient z počítače klient.firma.cz navazuje spojení na portu 1500 se serverem na portu 23 (předpokládejme, že pro tento příkaz telnet byl operačním systémem počítače server.firma.cz přidělen port 2500).

 

Pokud na počítači klient.firma.cz na portu 113 běží server pro identifikační protokol (obvykle se jmenuje identd, ale např. program inetd může interně fungovat jako takový server), pak obdržíte buď kladnou odpověď: 

23, 1500 : USERID : UNIX : dostalek

tj. toto spojeni navazuje uživatel dostalek. Nebo obdržíte zápornou odpověď: 

23, 1500 : ERROR : chybová hláška

Tj. žádný uživatel takové spojení z počítače klient.firma.cz nenavazuje, tj. jedná se o napadení typu "address spoofing attack" (nebo server pro identifikační protokol lže).

 

Na  obrázku 4-8 je příklad identifikačního protokolu podle RFC-1413 rekapitulován.


 

Obr. 4-8 Telnet a identifikační protokol

4.6                           Protokoly RADIUS a TACACS+

Dalšími protokoly, se kterým je třeba se seznámit, jsou protokoly RADIUS a TACACS+.  Jedná se o velice důležité protokoly v Internetu, ale z hlediska bezpečné komunikace bývají někdy ne zcela správně aplikovány i pro přístup pracovníků na cestách do vnitřní sítě.

 

Dále se budeme zabývat pouze protokolem RADIUS, jež je oficiálním protokolem Internetu (RFC-2865); protokol TACACS+ v praxi podporovaný firmou CISCO je protokolem s velice podobnými vlastnostmi a nakonec i zařízení firmy CISCO dnes podporují oba protokoly.

 

Cílem protokolu RADIUS je provádět centralizovanou autentizaci uživatelů připojujících se na přístupové servery.

 

 

Obr. 4-9 Protokol RADIUS

Přístupový server je box obsahující směrovač, jež se umí tvářit pro některé uživatele i jako terminálový server (terminálový server je zařízení, které se používalo v minulosti – jedná se o box, na který se připojovaly terminály a který zprostředkovával spojení připojených terminálu se serverem po LAN). Posláním přístupového serveru je umožnit přistupovat do sítě nejenom lokálním uživatelům a uživatelům připojeným pevnými linkami, ale zejména uživatelům připojeným komutovanými linkami.

 

Součástí přístupového serveru bývá i jednotka modemů, na kterou volají uživatelé. Zpravidla máme pro jednotku přidělenu sérii telefonních čísel, na které uživatelé volají. Poskytovatelé telefonních služeb většinou označí jedno telefonní číslo jako vedoucí číslo série, které poskytují uživatelům. Uživatelé volají stále na jedno číslo a poskytovatel převádí vedoucí číslo série na neobsazené číslo ze série.

 

Pokud jsme s poskytovatelem telefonních služeb propojeni digitálně (např. dělenou  E1), pak do přístupového serveru vložíme desku, která zajistí připojení sjednaného počtu klientů protokolem V.90 a sjednaného počtu klientů protokolem ISDN.

 

Klient je fyzicky vždy připojen na konkrétní port přístupového serveru. Je třeba nezaměňovat port přístupového serveru (jež je fyzicky reprezentován konektorem na přístupovém serveru) s portem protokolů TCP či UDP.

 

Pokud se klient připojí k přístupovému serveru (na úrovni modemů vše proběhlo OK), pak přístupový server prověřuje oprávnění uživatele přistoupit do sítě. Tato oprávnění mohou být lokálně nastavena v přístupovém serveru, to je však při použití více přístupových serverů velice nepraktické.

 

Centralizaci autentizačních informací pro přístupové servery řeší právě protokol RADIUS (resp. TACACS+). Přístupový server coby klient protokolu RADIUS se dotáže serveru protokolu RADIUS, zda-li může uživatele do sítě propustit a za jakých podmínek. RADIUS server pak např. odpoví, že ano, ale že přístupový server má tomuto uživateli aktivovat ty a ty filtry.

 

Protokol RADIUS je protokolem mezi přístupovým serverem a RADIUS serverem udržující ověřit a předat přístupové informace uživatelů.

 

RADIUS protokol je aplikační protokol, který využívá protokol UDP, tj. datagramovou službu obdobně jako DNS. Důvodem je skutečnost, že je nutná rychlá odezva přístupového serveru v okamžiku přihlášení se uživatele. Podobně jako v DNS můžeme provozovat více RADIUS serverů a v případě neobdržení či zpoždění odpovědi od prvního RADIUS serveru zopakujeme dotaz na další RADIUS server atd. Server protokolu RADIUS je zpravidla spuštěn na  portu 1812/udp.

 

Protokol RADIUS používá čtyři typy zpráv:

 

 

Obr. 4-10 Formát paketu protokolu RADIUS

 

Na obr. 4-10 je zobrazen formát paketu protokolu RADIUS. Paket začíná kódem specifikujícím, zdali se jedná o zprávu Access-Request, Access-Accept, Access-Reject či Access-Challenge. Dále následuje identifikátor zprávy sloužící k párování dotazů a odpovědí, tj. klient generuje identifikátor a server tento identifikátor zkopíruje do své odpovědi.

 

Autentifikátor slouží k prokázání pravosti odpovědi serveru.

 

Protokol RADIUS se zabývá dvěma druhy autentizace:

·         Autentizace klienta přihlašujícího se k přístupovému serveru. Toto je cílem protokolu RADIUS, ale pro protokol RADIUS to jsou jen aplikační data. RADIUS server může implementovat celou řadu autentizačních mechanismů a přitom na protokolu RADIUS to nic nemění.

·         Autentizace RADIUS serveru vůči přístupovému serveru (tj. vůči RADIUS klientu). Podstatou protokolu RADIUS je, že se autentizační server dotazuje RADIUS serveru, zdali má klientovi umožnit přístup do sítě či nikoliv. Podvržený RADIUS server by mohl povolit přístup do sítě  neoprávněným uživatelům, proto si RADIUS klient (přístupový server) musí být jist, že se jedná o odpověď od nepodvrženého RADIUS serveru.  RADIUS server proto do své odpovědi vloží řetězec, kterým svou odpověd autorizuje.

 

Autorizace RADIUS serveru

Autentizace probíhá na základě sdíleného tajemství, které zná pouze RADIUS server a RADIUS klient. Klient vygeneruje do pole autentifikátor náhodný řetězec. Server pak do téhož pole vrátí kontrolní součet počítaný algoritmem MD5 z celého vraceného paketu zřetězeného se sdíleným tajemstvím.

 

Autentizace uživatele

RADIUS server může podporovat celou řadu autentizačních mechanismů: od autentizace jménem uživatele a heslem, přes podporu protokolů PAP a CHAP až po autentizaci jednorázovým heslem.

 

Pokud se uživatel autentizuje heslem, pak se jméno uživatele i heslo přenáší ve zprávě Access-Request. Na takovouto zprávu může po ověření hesla následovat buď zpráva Access-Accept či Accept-Reject. 

 

Při autentizaci heslem se uživatelské jméno přenáší v atributu „User-Name“ a heslo v atributu „User-Password“. Je třeba si i při této relativně jednoduché autentizaci uvědomit, že vždy máme dva dialogy:

  1. Dialog mezi uživatelem a přístupovým serverem, jehož cílem je získat informace pro sestavení zprávy Access-Request. Tento dialog se může skládat z několika dotazů a odpovědí (např. dotaz na jméno, odpověď uživatele s jeho jménem, dotaz na heslo a odpověď s heslem).
  2. Dialog protokolu RADIUS obsahující např. zprávy Access-Request a Access-Accept.

 

V případě, že RADIUS server pro daného klienta zjistí, že je požadována autentizace jednorázovým heslem, tj. typu výzva/odpověď  (Challenge/Response), pak RADIUS server odpoví zprávou typu Access-Challenge obsahující výzvu. Zprávu Access-Challenge zpracuje přístupový server v dialog vyzývající uživatele k zadání jednorázového hesla. Přístupový server pak sestaví novou zprávu Access-Request s novým identifikátorem jednorázového hesla v atributu „User-Password“. Otázkou je, jak spárovat zprávu Access-Challenge s nově vytvořenou zprávou Access-Request. Pro tyto účely slouží atribut „State“. Server do zprávy Access-Challenge vloží identifikaci do atributu „State“ a klient pak tento atribut zkopíruje do nově vytvářené zprávy Access-Request.

 

Je zajímavé si uvědomit, že tento mechanismus není třeba pro protokol CHAP. Proč? Pokud klient kontaktuje přístupový server např. protokolem PPP a v něm použije autentizaci CHAP, pak přístupový server pozná, že se chce klient autentizovat protokolem CHAP. Přístupový server proto nemusí pro zadání výzvy kontaktovat RADIUS server, ale vygeneruje sám generátorem náhodných čísel náhodnou výzvu pro protokol CHAP, kterou pošle uživateli. Software uživatele vygeneruje jednorázové heslo a až po jeho obdržení generuje přístupový server (RADIUS klient) zprávu Access-Request, kde mj. naplní:

 

Jinými slovy: zpráva Access-Challege je určena pro autentizaci pomocí autentizačních kalkulátorů či obdobných pomůcek.

 

4.6.1                     Protokol RADIUS Accounting

RADIUS Accounting protokol slouží k zaznamenávání přihlášení a odhlášení uživatelů k přístupovému serveru. Tento protokol používáme zpravidla:

  1. V případě používání přístupového serveru pro práci zaměstnanců z domova či na cestách v podnikové síti, je pak možné RADIUS Accounting protokolem sledovat, kdy a jak byl který zaměstnanec (resp. útočník) přihlášen.
  2. V případě poskytovatelů Internetu se RADIUS Accounting protokolem sleduje, kdy a jak byl který zákazník přihlášen. Dále je možné zjistit, kolik zdrojů čerpal, tj. jak dlouho byl přihlášen, kolik přenesl bajtů, kolik přenesl rámců atp. Jinými slovy RADIUS Accounting protokol poskytuje informace pro zpoplatňování zákazníků poskytovatelů Internetu, ze kterého může v konečném důsledku být vytvořena až i faktura pro zákazníka.

 

RADIUS Accounting protokol je velice podobný protokolu RADIUS. Server RADIUS Accounting protokolu se zpravidla spouští na portu 1813/udp. Použití protokolu UDP opět řeší nedostupnost serveru. Nevýhodou však je, že musíme slévat záznamy ze všech serverů dohromady, pokud chceme zjišťovat různé statistiky či vytvořit fakturu pro zákazníka poskytovatele Internetu. Při slévání záznamů z jednotlivých serverů může dojít k duplikacím údajů. Proto je nutné tyto záznamy čistit před tvorbou faktury.

4.7                           Kerberos

Systém Kerberos je určen pro autentizaci uživatelů v případě přihlášení uživatele k systému či autetnizace uživatele vůči serveru (službě). Jedná se o poměrně letitý systém, jehož aktuální verze 5 je standardizována v RFC-1510 z roku 1993. Dnes se však stal aktuálním zejména proto, že Windows 2000 jej použily jako základní autentizační mechanismus pro uživatele. Bohužel firma Microsoft provedla ve své implementaci takové úpravy, že výsledný systém Kerberos není kompatibilní s žádnou jinou rozšířenou implementací.

 

Snad díky svému stáří používá Kerberos zcela odlišnou terminologii než jiné systémy. Např. místo slova uživatel používá termín principál. Principál však není pouze uživatel, ale např. i server (služba), ke kterému se chce uživatel pomocí systému Kerberos přihlásit. Podobně Kerberos používá termín „realm“ pro doménu, tj. pro oblast, ve které je platné jméno principála. Globálně je principál pak určen dvojicí jméno principála a názvem „realm-u“.

 

Systém Kerberos je určen pro přihlášení se uživatele k systému či autentizaci uživatele vůči serveru v rámci intranetu. Tj. nejedná se o protokol, který by se masově používal v Internetu, tj. vzájemně mezi „cizími“ uživateli. Přesto uvědomíme-li si, že namísto dále popsaného mechanismu na základě symetrické kryptografie je stejně tak dobře možné použít asymetrickou kryptografii s certifikáty, pak ve své podstatě nic nebrání použití Kerbera i ve veřejných aplikacích.

 

Systém Kerberos neřeší otázku šifrování dat, integrity přenášených dat či snad elektronického podpisu dat – zabývá se pouze autentizací uživatele.

 

Pokud se k nějakému systému hlásíme pomocí jména uživatele a hesla, pak je heslo sdíleno jako tajemství mezi uživatelem a systémem (přesněji, správcem systému). V kap. 4.1 jsme uvedli, že na straně systému nebývá heslo uloženo přímo, ale znehodnoceno nějakou jednocestnou funkcí (kontrolním součtem) právě jako jistá ochrana proti správci systému. Uživatel se pak autentizuje tím, že heslo zašle systému. Nebezpečím přitom je, že heslo bude odchyceno a následně zneužito útočníkem.

 

Kerberos používá jiný neotřelý mechanismus. Uživatel neposílá nezabezpečenou sítí heslo útočníkovi před očima, ale použije jej jako šifrovací klíč, kterým zašifruje mj. jméno uživatele a aktuální čas. Serveru pak pošle místo klasického hesla tento zašifrovaný řetězec jako heslo (a také mu nešifrovaně zašle jméno uživatele).

 

Server nalezne podle jména uživatele jeho šifrovací klíč a řetězec dešifruje. Pokud se zaslané jméno shoduje se jménem v zašifrovaném řetězci a datum a ostatní údaje jsou akceptovatelné, pak je klient autentizován. Všimněte si, že heslo musí být známo jak klientovi, tak v nezměněné formě i serveru. Pro úplnost je třeba dodat, že pokud si klient zvolí nějaké slovo jako heslo, pak toto slovo musí být „přežehleno“ nějakou rozumnou funkcí do zmíněného šifrovacího klíče (to však musí dělat jak software klienta, tak i software serveru). V případě asymetrické kryptografie pak na straně serveru stačí, aby u jména uživatele byl udržován certifikát, resp. identifikace certifikátu.

 

V každém případě musí být databáze uživatelů a jejich klíčů dostatečně chráněna, protože je jádrem vnitropodnikové bezpečnosti. V případě použití asymetrické kryptografie pak není nebezpečná distribuce klíčů (tj. předání uživatelem generovaného klíče správci databáze), ale citlivé je přiřazení uživatel – jeho certifikát (resp. jeho předmět certifikátu).

 

Nyní si popišme alespoň základní myšlenky systému Kerberos (obr. 4-11). Jádrem systému je „Centrum distribuce klíčů systému Kerberos“ (Key Distributin Center - KDC).

Obr. 4-11 Kerberos se skládá ze tří základních služeb: AS, TGS a CS

Nad KDC běží dvě služby:

 

Třetí služba Kerbera běží na aplikačním serveru, jehož služby si přeje uživatel využívat:

 

Na obr. 4-11 je malý pejsek nakreslen i nad uživatelem. To je velice důležité; i když je Kerberos sofistikovaný systém, tak má jednu nevýhodu: software na straně klienta (uživatele) i na straně serveru musí být upraven pro použití Kerbera – musí být „kerberizován“. Kerberizace spočívá v nahrazení stávající autentizace aplikací, která provádí autentizaci Kerberem (což prakticky bývá nahrazení dvou volání). Pokud jsou k dispozici zdrojové texty, tak kerberizace není teoreticky až takový problém, avšak prakticky zamezila masovému rozšířeni Kerbera. Důležité je, že Windows 2000 jsou kerberizovány již od výrobce, a to jak na straně klienta, tak i na straně serveru. KDC pak běží jako služba Active Directory, tj. do domény Windows 2000 je možné vkládat i systémy na bázi operačního systému UNIX (obráceně je to netriviální).

 

Nyní si popíšeme tři služby Kerbera.

 

4.7.1                     Služba AS

Služba AS běží na KDC (obr. 4-12). Pomocí služby AS se uživatel autentizuje vůči KDC. Uživatel odešle dvojici: svou identifikaci a řetězec zašifrovaný svým klíčem. Tento řetězec obsahuje identifikaci uživatele a čas.

 

 

Obr. 4-12 Služba AS

Kerberos ve své databázi najde záznam pro tohoto uživatele. V záznamu je i jeho šifrovací heslo, kterým dešifruje řetězec. Kerberos v dešifrovaném řetězci kontroluje jméno uživatele a mj. zkontroluje, jestli je čas uvedený uživatelem akceptovatelný.

 

V případě, že ověření uživatele proběhne úspěšně, pak Kerberos vydá uživateli „lístek pro vydávání lístků - TGT“. Myšlenka spočívá v tom, že „lístek pro vydávání lístků“ je jednodušším a tím i rychlejším mechanismem než autentizace pomocí hesla. Tj. při následující autentizaci klienta bude možné, aby se klient autentizoval pomocí lístku na vydávání lístků a nemuselo se vyhledávat v databázi.

 

Lístek pro vydávání lístků se vydává na dobu několika hodin pro konkrétního uživatele pracujícího na stanici o konkrétní IP adrese a případně o konkrétní linkové adrese.

 

Lístek pro vydávání lístků je struktura obsahující identifikaci uživatele a šifrovací klíč (na obr. 4-12 klíč-uživatel). Tato struktura je zašifrována šifrovacím klíčem TGS, tj. do ní se dostane pouze TGS a nikdo jiný. Spolu s lístkem pro vydávání lístků obdrží uživatel i strukturu obsahující identifikaci uživatele a šifrovací klíč (na obr. 4-12 klíč-uživatel), ale zašifrovanou uživatelovým šifrovacím klíčem. Tj. Kerberos vygeneruje šifrovací klíč a předá jej uživateli. Kerberos i uživatel sdílí šifrovací klíč. Tento šifrovací klíč se nazývá šifrovacím klíčem relace pro komunikaci uživatele s KDC. Pomocí tohoto klíče bude uživatel žádat o vydání lístků po používání jednotlivých služeb.

4.7.2                     Služby TGS a AS

Nyní již má uživatel vydán „lístek pro vydávání lístků“. Pomocí něj bude Kerbera žádat o vydání lístků pro relace s konkrétními servery (obr. 4-13).

 

Chce-li uživatel využívat nějakou službu (server), pak Kerberovi odešle požadavek obsahující:

 

Kerberos dešifruje lístek pro vydávání lístků (jedině on má k němu dešifrovací klíč). Dešifrováním lístku pro vydávání lístků Kerberos získá šifrovací klíč relace, kterým dešifruje řetězec. Z řetězce získá identifikaci uživatele, kterou porovná s identifikací uvedenou v požadavku na službu. Dále Kerberos zkontroluje čas požadavku a IP adresu uživatelovy stanice a případně linkovou adresu stanice.

 

Pokud vše dopadne dobře, pak Kerberos uživateli vydá:

 

Klient si pak pomocí lístku relace řekne serveru o poskytnutí služby. Klient při této příležitosti serveru odesílá:

·         Svou identifikaci a čas šifrovaný klíčem relace.

·         Lístek relace, který je šifrovaný klíčem serveru.

 

Server si dešifruje lístek relace. Tím získá klíč relace, kterým dešifruje požadavek uživatele. Server zjišťuje, zdali je v obou případech shodná identifikace uživatele; zdali je akceptovatelný čas; dále může ještě kontrolovat, zdali byl lístek relace uplatněn ze stanice o adrese uvedené v lístku atd.

 

Je-li vše v pořádku, pak je uživatel vůči serveru autentizován a server poskytne požadovanou službu.

 

Obr. 4-13 Služby TGS a CS

4.7.3                     Lístky

Kerberos používá lístek jako svůj základní mechanismus. Lístek je vydán vždy na omezenou dobu. Pokud však lístek vyprší během navázané relace,tato pokračuje dále, protože lístek se použije pouze při zřízení relace. Jiným problémem je, že klíče relace by měly být obnovovaný, aby útočníkovi, který odhalí klíč relace, netrvalo jeho štěstí příliš dlouho. Jenže jak obnovit klíč relace, když byl distribuován jako součást lístku relace?

 

Řešením jsou tzv. obnovitelné lístky. KDC vydá lístek, který je platný delší dobu, ale označí jej, že je obnovitelný. Zároveň do tohoto lístku vyznačí, po jaké době by měl být obnovován klíč relace. Klient je pak povinen si od KDC do této doby nechat vydat nový – obnovený lístek. Ten se od původního lístku liší minimálně – v klíči relace. Poté co klient předá server obnovený lístek, tak je nový klíč distribuován, tj. je znám jak klientovi, tak serveru.

 

Jiným problémem je, že klient přistupuje např. na aplikační server (FrontEnd), který žádá o službu, ale aplikační server o příslušná data musí požádat databázový server (BackEnd). Aplikační server by měl přistupovat do databáze jménem klienta, tj. s přístupovými právy klienta. Jenže databázový server potřebuje pro takový přístup lístek relace od klienta. Ve své podstatě jej nepotřebuje od klienta, ale potřebuje jej od aplikačního serveru jako by byl od klienta. Takový lístek se nazývá proxy lístek. Proxy lístek nechá vydat klient pro aplikační server, aby aplikační server mohl jménem klienta přistoupit do databáze (tj. TGS musí v proxy lístku klíč relace šifrovat klíčem aplikačního serveru – nikoliv klíčem klienta).

 

Nevýhodou proxy lístku je skutečnost, že klient musí znát název služby na BackEndu. Pokud je např. klient z Internetu a BackEnd ve vnitřní síti, tak je to nepříjemné.

 

Jiným řešením je, že si klient pro aplikační server nechá vydat lístek pro vydávání lístků (TGT). FrontEnd si pak jménem klienta nechá vydat pro BackEnd příslušný lístek relace, aniž by klient musel znát jméno služby na BackEndu. Jenže jsou tu zase jistá bezpečnostní rizika pro klienta – co když si FrontEnd nechá vydat jménem klienta lístek relace i pro jiný server než klient chtěl?