Kerberos

W pierwszym odcinku cyklu poruszyłem istotność kwestii ochrony danych w Internecie. Opisałem też algorytm Diffiego-Hellmana będący podstawą wielu systemów bezpiecznej wymiany danych. W tym odcinku chciałbym przedstawić konkretny system - Kerberos. Jest on interesujący co najmniej z dwu powodów: po pierwsze jest dość rozpowszechniony i obecnie udostępniany jako część składowa wielu "poważnych" systemów operacyjnych, po drugie, Kerberos interesujący jako przykład dobrze pomyślanej, praktycznej realizacji bezpieczeństwa danych w systemie rozproszonym.

Kerberos opracowany został w Massachusetts Institute of Technology, w ramach projektu Atena. Wywodzi się więc z miejsca będącego kolbką wielu nowatorskich rozwiązań z dziedziny informatyki, a technologii sieciowych w szczególności. Teoretyczne podstawy protokołu Kerberos powstały na początku lat osiemdziesiątych, pierwsza implementacja w 19987-88 r. W ciągu dziesięciu lat swojego istnienia system był intensywnie rozwijany i obecnie doczekaliśmy się jego piątej wersji, której dotyczy niniejszy artykuł.

Do czego służy Kerberos?

Kerberos realizuje bezpieczeństwo w sieci w trzech aspektach: umożliwia weryfikację tożsamości komunikujących się stron, zapewnia integralność przesyłanych danych, zapewnia poufność danych. Zaznaczmy, że dwa ostatnie punkty są opcjonalne, tzn. integralność i poufność mogą, ale nie muszą być realizowane przez konkretne aplikacje współpracujące z systemem.

W skład system Kerberos wchodzą serwery bezpieczeństwa, serwery aplikacji i danych oraz "kerberyzowani" klienci - specjalnie przystosowane aplikacje. W ścisłym sensie, Kerberos jest protokołem sieciowym warstwy aplikacji.

Założenia.

Założenia systemu Kerberos są następujące:

• Działa on w środowisku rozproszonym, w którym nie można ufać komputerom, można zaś ufać użytkownikom - oczywiście w ramach przysługujących im uprawnień i po skontrolowaniu tożsamości przy pomocy hasła.

• Nie ufamy (lub nie musimy ufać): zabezpieczeniom systemu operacyjnego klienta, poprawności jego adresu, fizycznemu bezpieczeństwu sieci (ale zobacz ostatni punkt).

• Musimy zaufać fizycznemu bezpieczeństwu serwera Kerberos - fizycznemu - gdyż podszycie się innej maszyny pod serwer jest dzięki własnościom protokołu bardzo utrudnione. Zaufanie fizyczne odnosi się też do baz danych serwera, np. do nośników z kopiami zapasowymi bazy!

• Kerberos nie uchroni naszej sieci przed atakami o charakterze psychologiczno-socjotechnicznym polegających na wyłudzeniu, przechwyceniu lub zgadnięciu hasła należącego do danej osoby.

• Wbrew temu, co często można przeczytać na temat Kerberosa, nie jest on całkowicie odporny na ataki polegające na podszywaniu się komputera włamywacza pod inny komputer. Zagadnienie to zostanie omówione nieco szerzej pod koniec artykułu.

Koncepcja techniczna.

Istota systemu polega na wydawaniu przez uprawniony, centralny serwer tak zwanych "biletów" (tickets) do konkretnych usług sieciowych. Użytkownik chcąc np. przeczytać pocztę musi uzyskać bilet umożliwiający dostęp do serwera poczty, chcąc sięgnąć do pliku umieszczonego na sieciowym serwerze plików musi uzyskać inny bilet, itd. Uzyskanie biletu wymaga każdorazowo weryfikacji tożsamości, poprzez podanie hasła. Bilety są zaś ważne tylko przez określony czas (zwykle kilka - kilkanaście godzin), tak więc nawet kradzież biletu, jako zjawisko jednostkowe nie ma większego wpływu na bezpieczeństwo systemu. Bilety moją inną ciekawą własność - są szyfrowane. Klient uzyskuje bilet, którym posłuży się do uzyskaniu dostępu do danego serwera, nie może jednak biletu ani odkodować, ani tym bardziej zmieniać. Oczywiście, to samo odnosi się do ewentualnego "podsłuchiwacza".

Informacje uwierzytelniające oraz bilety są szyfrowane przy pomocy algorytmu typu DES. ¯adna poufna inoformacja nie jest nigdy przekazywana otwartym tekstem.

Charakterystyczną cechą protokołu Kerberos jest to, że system bezpieczeństwa pośredniczy tylko w nawiązaniu łączności pomiędzy klientem a serwerem, dalsza komunikacja odbywa się już bez udziału Kerberosa, jest to oczywiście korzystne ze względu na wydajność.

Uważny czytelnik zauważył być może niepokojący fakt - każda usługa wymaga weryfikacji tożsamości użytkownika! W praktyce oznaczałoby to konieczność podawania hasła przy uruchomieniu każdego programu korzystającego z zasobów sieciowych (a nawet częściej). Takie rozwiązanie jest oczywiście trudne do zaakceptowania, choć istnieją super-bezpieczne systemy, które je stosują. Kerberos rozwiązuje ten problem inaczej: użytkownik rozpoczynając sesję i uwierzytelniając się hasłem uzyskuje "bilet na bilety" (ticket granting ticket). Wydawanie biletów do konkretnych usług jest już zautomatyzowane i nie wymaga interwencji użytkownika.

Działanie systemu.

Uwierzytelnianie dostępu klienta do usług świadczonych przez dany serwer sieciowy jest procesem wieloetapowym obejmującym wymianę komunikatów pomiędzy klientem, serwerem uprawnień, serwerem biletów i serwerem sieciowym. Uwierzytelnianie przebiega w protokole Kerberos następująco:

1. Użytkownik rozpoczyna pracę na stacji roboczej, podaje swój identyfikator, który jest przekazywany do serwera uprawnień (key-distribution center.). Identyfikator użytkownika jest przekazywany otwartym tekstem, gdyż szyfrowanie go nie jest potrzebne.

1. Serwer uprawnień konstruuje bilet do serwera biletów (ticket granting server). Bilet ten jest szyfrowany kluczem serwera biletów i tylko przez niego może być odczytany. Serwer uprawnień generuje następnie losowy klucz sesji oraz odczytuje ze swojej bazy danych klucz użytkownika. Ostatecznie bilet do serwera biletów i klucz sesji zostają zaszyfrowane kluczem użytkownika i przesłane do niego.

1. Komputer klienta otrzymuje wysłane przez serwer informacje, pyta użytkownika o hasło, przekształaca hasło na klucz użytkownika. Tak uzyskany klucz powinien być tym samym kluczem, którego użył serwer uprawnień. Informacje uzyskane od serwera uprawnień mogą być teraz odszyfrowane. Klient uzyskuje klucz sesji i bilet do serwera biletów - "bilet na bilety".

1. "Bilet na bilety" umożliwia dostęp do pozostałych serwerów sieciowych. W celu uzyskania dostępu np. do serwera plików klient przekazuje serwerowi biletów "bilet na bilety" oraz informacje o serwisie, do którego chce uzyskać dostęp.

1. Serwer biletów uzyskawszy zgłoszenie klienta sprawdza poprawność "biletu na bilety", a następnie podobnie jak robił to serwer uprawnień konstruuje bilet do konkretnego serwera, w naszym przypadku serwera plików. Bilet do serwera plików jest zaszyfrowany kluczem serwera plików i podobnie jak było w przypadku "biletu na bilety" nie może być odszyfrowany przez klienta. Serwer biletów zwraca nowy bilet klientowi, cały komunikat jest szyfrowany kluczem sesji.

1. Klient posługuje się otrzymanym biletem do uzyskania dostępu do serwera plików.

1. Serwer plików po uzyskaniu od klienta biletu, sprawdza czy bilet jest poprawny, jeżeli tak, to klient uzyskuje dostęp do serwera plików. Szyfrowania danych pomiędzy klientem a serwerem plików jest przeprowadzane w oparciu o nowy klucz sesji, który został wygenerowany wcześniej przez serwer biletów i przekazany klientowi wraz z biletem do serwera plików.

1. Chcąc uzyskać dostęp do innego serwera klient posługuje się "biletem na bilety", powtarza się cykl 4 -6

W powyższym opisie pominięto szereg istotnych szczegółów. Istotna jest zawartość biletów: bilet prócz adresu serwera zawiera czas utworzenia, czas ważności oraz klucz sesji. Dzięki temu serwer biletów mógł zaszyfrować informację zwracaną do klienta w p. 5 dobrym kluczem sesji. Podobnie bilet dla serwera plików również zawiera nowy klucz sesji. Tak więc do klienta nowy klucz sesji jest zwracany w dwu postaciach: zaszyfrowany jego własnym kluczem (przy pierwszym zgłoszeniu) lub kluczem sesji (w odpowiedziach serwera biletów) oraz zawarty w nowym bilecie. Drugi waży aspekt to weryfikacja klienta oraz serwera: prócz biletów klient przekazuje do serwera biletów oraz serwera właściwego informacje uwierzytelniające (m.in swoją nazwę i aktualny czas). Serwer po odszyfrowaniu biletu sprawdza czy informacje uwierzytelniające zgadzają się z zawartymi w bilecie. Dzięki temu klient nie może posłużyć się cudzym biletem, biletem przestarzałym lub biletem do innego serwera. Z kolei serwer odpowiadając klientowi zwieksza o jeden zaszyfrowany czas uzyskany od klienta - komputer podszywający się pod serwer nie umiał by tego zrobić, gdyż nie posiadał by odpowiedniego klucza szyfrującego, mógłby jedynie wydawać fałszywe bilety.

Bilety wydane przez serwer biletów ważne są przez kilka - kilkanaście godzin, zaś informacje uwierzytelniające przekazywane wraz z biletem pomiędzy klientem a danym serwerem sieciowym dezaktualizują się w ciągu kilku minut. Tym trudniejsze jest utworzenie sztucznego pakietu uwierzytelniającego transakcję ze skradzionego biletu. Oczywiście, rozwiązanie to pociąga za sobą konieczność zsynchronizowania z dokładnością do kilku minut, zegarów czasu astronomicznego wszystkich komputerów uczestniczących w systemie bezpieczeństwa.

Poufność i weryfikacja danych.

Generowane przez serwer uprawnień i serwer biletów klucze sesji służą odpowiednio do: szyfrowania informacji uwierzytelniających między klientem a serwerem kluczy oraz miedzy klientem a danym serwerem sieciowym. Klucze sesji mogą być też użyte do szyfrowania całej informacji wymienianej między klientem a serwerem oraz do weryfikacji danych. Weryfikacja może być wykonana poprzez wygenerowanie sumy kontrolnej i zaszyfrowanie jej kluczem sesji, rozwiązanie to jest korzystne gdy dane nie sa poufne, nie chcemy jednak by ktoś mógł je zmieniać.

Słabe strony i wady protokołu Kerberos.

Podczas już prawie dziesięcioletniej eksploatacji Kerberosa w MIT nie stwierdzono ani jednego przypadku złamania systemu. Świadczy to o nim bardzo dobrze. Kerberos posiada jednak sporo wad nie wynikających bezpośrednio z samej koncepcji kryptograficznej, lecz raczej z przyjętej implementacji. Serwer upoważnień oraz serwery biletów są najwrażliwszymi ogniwami systemu. Muszą być chronione fizycznie, gdyż ich uszkodzenie lub penetracja były by katastrofalne dla całej sieci. W systemach sieciowych znane są techniki rozpraszania krytycznych zasobów, problem polega na tym, że wraz ze zwielokrotnianiem poufnej informacji jest ją coraz trudniej chronić. Kerberos nie jest też zbyt dobrze przygotowany do pracy w środowiskach liczących bardzo wielu użytkowników. Co prawda, został on rozszerzony o mechanizmy domenowe (baza danych nie musi być "płaska"), jednak trudno sobie wyobrazić weryfikację tożsamości wszystkich użytkowników Internetu przy pomocy systemu Kerberos! Tak jak każdy system bezpieczeństwa Kerberosa można pokonać, nie koniecznie poprzez włamanie - możliwe jest "obejście". Klasyczny przykład to oszukanie bezdyskowej stacji roboczej, która swój system operacyjny pobiera z serwera plików. Włamywacz podszywając się pod serwer może "posunąć" stacji bezdyskowej system operacyjny ze zmodyfikowanym klientem Kerberosa. Co stanie się dalej jest oczywiste - włamywacz przejmie kontrolę nad hasłami, kluczami i biletami użytkowników korzystających ze spenetrowanej stacji.

Praktyczne wykorzystanie.

Strona kliencka protokolu Kerberos wbudowana jest w niektóre odmiany systemu Unix. Opiszę ją tu krótko na przykładzie systemu Solaris (SunSoft). Kerberos umożliwia w tej implementacji weryfikację tożsamości protokołu RPC - a więc efektywnie sieciowego systemu plików NFS oraz usług "r" z Berkeley, tzn: rsh (zdalna powłoka), rlogin (praca ze zdalnym systemem), itd. Użytkownik uzyskuje "bilet na bilety" przy pomocy polecenia kinit, tak więc autoryzacja dostępu do systemu (login) oraz dostępu do serwerów Kerberosa jest rozłączna. Uzyskane bilety przechowywane są w pliku i mogą być niszczone przy pomocy polecenia kdestroy. Lokalny proces serwea - kerbd uzyskuje bilety dla usług RPC wbudowanych w jądro systemu. Poszczególne aplikacje, chcące korzystać z ochrony Kerberosa muszą same zgłaszać się po bilety, jest to zresztą zgodne z filozofią systemu. Szkopuł w tym, że prócz wymienionych usług "r" i NFS nie są dostarczone aplikacje współpracujące z Kerberosem - musimy sami zdobyć źródła lub binaria aplikacji "kerberyzowanych" lub przerabiać aplikacje dostępne w postaci źródłowej.

Przyszłość

Kerberos jest bardzo skutecznym i dopracowanym systemem bezpieczeństwa dla sieci lokalnych oraz większych - do poziomu organizacyjnego. Będzie najprawdopodobnie w użyciu przez długi czas i ulegnie dalszej standardyzacji. Nie należy się jednak spodziewać "kerberyzacji" Internetu.

Dostępność:

Kerberos jest dostępny dla szeregu nowszych wersji Unixa, zarówno darmowych (np. BSD) jak i komercyjnych. Warto zaznaczyć, że jest on standardem konsorcjum OSF (Open Software Foundation), natomiast sam protokół nie został do tej pory uznany za oficjalny standard internetowy, choć jest opisany w kilku dokumentach RFC. Darmowo dostępne są też źródła, co jest niebagatelnym faktem, gdyż współpraca aplikacji sieciowych z Kerberosem wymaga ich przeróbki. Kerberos jest protokołem poziomu aplikacji, teoretycznie może więc współpracować z dowolnymi protokołami niższego poziomu. W praktyce jest on dostosowany do pracy z protokołami Internetu - TCP/IP, a także: ISO, DECnet Phase IV, Appletalk, XNS i Chaos. Kerberos współpracuje z systemami domenowymi DNS i X.500.

Literatura

Protokół Kerberos opisany jest dość szczegółowo w dokumencie RFC1510. Aktualne informacje można znaleźć na liście dyskusyjnej kerberos@mit.edu (zapisy przez kerberos-request@mit.edu), lista ta jest też dostępna jako grupa dyskusyjna news:comp.protocols.kerberos. Szczegółowe informacje, dokumentacji i źródła dostępne są za pośrednictwem poczty elektronicznej: info-kerberos@mit.edu.

Rysunek: TYLKO W NETWORLD!

Podpis pod rysunkiem:

"Wymiana informacji uwierzytelniających i biletów między klientem, serwerem uprawnień, serwerem biletów oraz serwerem X"

Grzegorz Blinowski pracuje w Instytucie Informatyki Politechniki Warszawskiej, jest też właścielem firmy konsultingowej "CC" zajmującej się doradztwem w zakresie architektur klient-serwer, Internetu i bezpieczeństwa systemów komputerowych.