Kerberos (informatyka)

Kerberos – protokół uwierzytelniania i autoryzacji w sieci komputerowej z zastosowaniem centrum dystrybucji kluczy, zaprojektowany w Massachusetts Institute of Technology (MIT).

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

Instytut Techniczny Massachusetts stworzył Kerberosa w celu ochrony usług sieciowych dostarczanych w ramach projektu Athena. Protokół bazuje na opracowanym wcześniej protokole kluczy symetrycznych, stworzonym przez Rogera Needhama i Michaela Schroedera. Istnieje kilka jego wersji, przy czym 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, mimo że 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 1993 (uznana za przestarzałą po opracowaniu RFC 4120 ↓ w 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 Stanach Zjednoczonych sklasyfikowały Kerberosa jako „dodatkowe wyposażenie wojskowe” i zakazały jego eksportu, ponieważ 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 Technicznym w Sztokholmie, sprawiła że system ten stał się dostępny poza granicami Stanów Zjednoczonych, zanim władze amerykańskie zmieniły politykę eksportu kryptografii (około 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, nazwanej 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.
  • nowej edycji specyfikacji GSS-API (ang. generic security services application program interface), nazwanej 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 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 instytucje akademickie (Królewski Instytut Techniczny, Uniwersytet Stanforda, MIT).

Opis protokołu

Najpierw następuje uwierzytelnienie klienta na serwerze (ang. authentication server – AS), który przesyła nazwę użytkownika do centrum dystrybucji kluczy (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

  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

  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: 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

  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

  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

  • 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 do 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

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