Kerberos (informatyka)

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

Kerberosprotokół uwierzytelniania i autoryzacji w sieci komputerowej z wykorzystaniem Centrum Dystrybucji Kluczy, zaprojektowanym w Massachusetts Institute of Technology.

Powstało też wiele interfejsów programistycznych pozwalających wbudowywać mechanizmy bezpieczeństwa dostarczane przez serwer Kerberos do aplikacji. Jednym z nich jest interfejs w języku Java nazwany General Security Service.

Historia i rozwój[edytuj]

Massachusetts Institute of Technology (MIT) stworzył Kerberosa w celu ochrony usług sieciowych, dostarczanych w ramach tzw. Projektu Athena. Protokół bazuje na opracowanym wcześniej protokole kluczy symetrycznych, stworzonym przez Rogera Needhama i Michaela Schroedera. Istnieje kilka wersji protokołu, z czego wersje od 1 do 3 występowały jedynie wewnętrznie w MIT.

Steve Miller i Clifford Neuman, pierwsi projektanci czwartej wersji Kerberosa, opublikowali ją w latach osiemdziesiątych, pomimo iż pierwotnie planowali ją wdrożyć dla projektu Athena.

Wersja 5, opracowana przez Johna Kohla i Clifforda Neumana, wystąpiła jako standard RFC 1510 w roku 1993 (uznana za przestarzałą po opracowaniu RFC 4120 w roku 2005). Głownym powodem implementacji tej wersji było zlikwidowanie ograniczeń oraz problemów z bezpieczeństwem, występoujących w wersji 4.

Władze w USA sklasyfikowały Kerberosa jako "Dodatkowe wyposażenie wojskowe" i zakazały jego eksportu ze względu iż używał on algorytmu Data Encryption Standard (DES) (wraz z kluczami 56-bitowymi).

Implementacja "nieamerykańskiej" czwartej wersji Kerberosa (KTH-KRB) została stworzona w Królewskim Instytucie Technologicznym w Sztokholmie w Szwecji, sprawiła że system ten stał się dostępny poza granicami USA, zanim władze Stanów Zjednoczonych zmieniły politykę eksportu kryptografii (ok roku 2000). Szwedzka wersja bazowała na edycji zwanej "eBones". Z kolei eBones bazował na eksportowanej edycji z MIT, która pozbawiona była zarówno funkcji szyfrujących, jak i odwołań do nich.

W 2005, grupa Internet Engineering Task Force (IETF) zaktualizowała specyfikacje. Zmiany dotyczyły m.in.:

  • Specyfikacji szyfrowania i sum kontrolnych (RFC 3961).
  • Szyfrowania za pomocą Advanced Encryption Standard (AES) dla Kerberosa 5 (RFC 3962).
  • Nowej edycji specyfikacji Kerberosa 5, nazwaną "The Kerberos Network Authentication Service (V5)" (RFC 4120). Ta wersja wyparła standard RFC 1510, wyjaśnia aspekty protokołu i przeznaczenie w sposób bardziej jasny i szczegółowy.
  • Nową edycję specyfikacji GSS-API (ang. Generic Security Services Application Program Interface), nazwaną

"The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

MIT stworzył ogólnodostępną implementację Kerberosa, której prawa autorskie były podobne do tych, używanych w ramach BSD. W 2007, MIT powołał konsorcjum Kerberosa w celu wsparcia dalszej implementacji protokołu. Sponsorami były m.in. Oracle, Apple Inc., Google, Microsoft, Centrify Corporation, TeamF1 Inc., a także akademickie instytucje takie jak Królewski Instytut Technologiczny w Sztokholmie w Szwecji, Stanford University oraz MIT.

Opis protokołu[edytuj]

Najpierw następuje uwierzytelnienie klienta na serwerze (ang. authentication server - AS), który przesyła nazwę użytkownika do Centrum Dystrybucji Kluczy (ang. key distribution center - KDC).

KDC tworzy unikatowy identyfikator (ang. ticket-granting ticket - TGT), szyfruje go za pomocą hasła użytkownika i zwraca zaszyfrowaną wartość do stacji użytkownika.

Logowanie klienta[edytuj]

  1. Użytkownik wprowadza login i hasło na maszynie klienta. Inne mechanizmy logowania, jak np. pkinit (RFC4556) pozwalają na użycie kluczy publicznych zamiast hasła.
  2. Klient konwertuje hasło na klucz symetryczny. Używany jest tutaj wbudowany klucz lub jednokierunkowa funkcja haszująca, w zależności od użytych narzędzi kryptograficznych.

Uwierzytelnienie[edytuj]

  1. Klient wysyła swoje ID w postaci jawnej wiadomości na serwer uwierzytelniający (AS).
  2. AS generuje klucz tajny, konwertując hasło użytkownika znalezione w bazie danych
  3. AS sprawdza obecność klienta w bazie. Jeżeli się tam znajduje, AS wysyła 2 wiadomości zwrotne:
    • Wiadomość A: Klucz sesji klienta, zaszyfrowany tajnym kluczem klienta
    • Wiadomość B: Tzw. 'Ticket-Granting-Ticket' - zawiera ona ID klienta, adres jego sieci i klucz sesji klienta, zaszyfrowane tajnym kluczem TGS.
  4. Gdy klient otrzyma wiadomości A oraz B, rozpoczyna odszyfrowywanie wiadomości A za pomocą tajnego klucza wygenerowanego z hasła użytkownika. Jeżeli hasło wprowadzone przez użytkownika nie odpowiada jego hasłu z bazy AS, tajny klucz użytkownika będzie inny i tym samym nie będzie on w stanie odszyfrować wiadomości A. Mając prawidłowy klucz, klient odszyfruje wiadomość. Ten klucz sesji będzie używany do dalszej komunikacji. Klient nie jest w stanie odszyfrować wiadomości B, ponieważ jest ona zaszyfrowana tajnym kluczem TGS.

Autoryzacja[edytuj]

  1. Wysyłając zapytanie o wykonanie usługi, klient wysyła do TGS następujące wiadomości:
    • wiadomość C: Zawiera ona TGT z wiadomości B oraz ID oczekiwanej usługi.
    • wiadomość D: Uwierzytelnienie (zawierające ID klienta i znacznik czasu), zaszyfrowane za pomocą klucza sesji klienta/TGS.
  2. Po uzyskaniu wiadomości C oraz D, TGS "wytwarza" wiadomość B na podstawie wiadomości C. Odszyfrowuje wiadomość B za pomocą tajnego klucza TGS. Tym samym tworzony jest klucz sesji klienta/TGS.  Przy użyciu tego klucza, TGS odszyfrowuje wiadomość D (uwierzytelnienie) i wysyła 2 następujące wiadomości do klienta:
    • Wiadomość E: Zawiera ona ID klienta, jego adres sieciowy, okres ważności  oraz klucz sesji klienta/serwera.Całość zaszyfrowana jest tajnym kluczem usługi.
    • Wiadomość F: klucz sesji klienta/serwera, zaszyfrowany kluczem sesji klienta/TGS

Zapytanie użytkownika[edytuj]

  1. Po otrzymaniu wiadomości E oraz F z TGS, klient ma wystarczającą ilość danych by zostać uwierzytelnionym na serwerze usług (ang. service server -  SS). Klient łączy się z SS i wysyła następujące wiadomości:
    • Wiadomość E z poprzedniego kroku
    • Wiadomość G - nowe narzędzie uwierzytelnienia, zawierające ID klienta, znacznik czasu. Zaszyfrowane kluczem sesji klienta/serwera.
  2. SS odszyfrowuje dane swoim własnym tajnym kluczem, by pozyskać klucz sesji klienta/serwera. Za pomocą klucza sesji, SS  odszyfrowuje wiadomość G i wysyła poniższą wiadomość do klienta by potwierdzić jego tożsamość i zgodę na wykonanie usługi:
    • Wiadomość H: Znacznik czasu, znajdujący się we wiadomości uwierzytelniającej klienta, zaszyfrowany kluczem sesji klienta/serwera.
  3. Klient odszyfrowuje wiadomość z potwierdzeniem za pomocą klucza sesji klienta/serwera. Ponadto sprawdza, czy znacznik czasu jest prawidłowy. Jeżeli jest, wówczas klient może uznać serwer za wiarygodny i może rozpocząć wysyłanie zapytań o usługi na ten serwer.
  4. Serwer rozpoczyna wykonywanie usług, o których wykonanie poprosi klient.

Wady i ograniczenia[edytuj]

  • Wymagana jest ciągła dostępność centralnego serwera. Gdy Kerberos będzie nieaktywny, nowi użytkownicy nie będą mieli możliwości logowania. Te skutki można złagodzić, używając kilku serwerów Kerberosa oraz alternatywnych mechanizmów uwierzytelniających.
  • Kerberos posiada restrykcyjne ograniczenia czasowe, co oznacza że zegary hostów muszą być zsynchronizowane zgodnie ze skonfigurowanymi limitami. Jeżeli zegar hosta nie będzie odpowiedni zsynchronizowany z serwerem Kerberosa,uwierzytelnienie się nie powiedzie. Według domyślnej konfiguracji,[1] różnica czasu powinna wynosić nie więcej niż 5 minut.
  • Protokół administracyjny nie posiada własnego standardu i różni się w zależności od implementacji serwerów. Zmiany haseł opisano w RFC 3244.
  • W przypadku symetrycznego szyfrowania (Kerberos może pracować zarówno z użyciem symetrycznych oraz asymetrycznych kluczy) - jako że wszelkie procesy uwierzytelniające są pod kontrolą centrum dystrybucji kluczy (KDC) - w razie zagrożenia infrastruktury uwierzytelniającej haker będzie mógł podszyć się pod dowolnego użytkownika.
  • Każda usługa sieciowa wymagająca innej nazwy hosta, będzie potrzebowała własnego zestawu kluczy.
  • Kerberos wymaga, aby wszystkie konta użytkowników, klienci oraz usługi na serwerze miały zaufane powiązanie z serwerem tokenowym Kerberosa (Wszystkie muszą być w tej samej domenie Kerberosa lub w domenach, mających zaufane powiązania pomiędzy sobą). Kerberosa nie można użyć w przypadku, gdy użytkownik chce skorzystać z usług za pomocą nieznanych/niezaufanych klientów, gdzie usługa uwierzytelniająca zazwyczaj "nie posiada" wiedzy odnośnie systemu klienta, z którego korzysta użytkownik.
  • Fakt, iż wymagany jest zaufany klient, sprawia iż tworzenie konkretnych środowisk (np., osobne domeny dla środowiska testowego oraz produkcyjnego) jest utrudnione: Albo należy utworzyć powiązanie pomiędzy domenami, które będzie zapobiegać rozdzieleniu domen środowiskowych lub należy utworzyć dodatkowych klientów dla poszczególnego środowiska.

Luki w zabezpieczeniach[edytuj]

Algorytm DES może być używany wraz z Kerberosem, lecz już nie jest obecnie stosowany jako standard gdyż uznany jest jako słaby szyfr.[2] Luki w zabezpieczeniach występują w wielu produktach, w których zastosowana jest implementacja Kerberosa, ponieważ nie były one aktualizowane w celu używania nowszych szyfrów od DES'a, takich jak AES.

W listopadzie 2014, Microsoft udostępnił aktualizację (MS14-068) w celu skorygowania wady, pozwalającej na nieprawidłowe korzystanie w implementacji Centrum Dystrybucji Kluczy (KDC) Kerberosa (dla systemu Windows).[3] W wyniku istnienia tej luki, użytkownicy mogli rzekomo "zwiększyć" swoje przywileje i tym samym mogli ich nadużywać.

Przypisy

Linki zewnętrzne[edytuj]