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łównym powodem implementacji tej wersji było zlikwidowanie ograniczeń oraz problemów z bezpieczeństwem, występują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ą tajnego klucza TGS 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 (RFC 4556 ↓) 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 odpowiednio 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

  1. Clock Skew - Kerberos V5 System Administrator's Guide, web.mit.edu [dostęp 2016-01-25].
  2. RFC 6649 ↓.
  3. Details emerge on Windows Kerberos vulnerability | ZDNet, www.zdnet.com [dostęp 2017-11-14] (ang.).

Linki zewnętrzne[edytuj]