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
[edytuj | edytuj kod]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
[edytuj | edytuj kod]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 (ang. Ticket Granting Server – TGS) i zwraca zaszyfrowaną wartość do stacji użytkownika.
Logowanie klienta
[edytuj | edytuj kod]- 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.
- 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 | edytuj kod]- Klient wysyła swoje ID w postaci jawnej wiadomości na serwer uwierzytelniający (AS).
- AS generuje klucz tajny, konwertując hasło użytkownika znalezione w bazie danych
- 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.
- 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 | edytuj kod]- 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.
- 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 | edytuj kod]- 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.
- 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.
- 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.
- Serwer rozpoczyna wykonywanie usług, o których wykonanie poprosi klient.
Wady i ograniczenia
[edytuj | edytuj kod]- 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
[edytuj | edytuj kod]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
[edytuj | edytuj kod]- ↑ Clock Skew – Kerberos V5 System Administrator’s Guide [online], web.mit.edu [dostęp 2016-01-25] .
- ↑ RFC 6649 ↓.
- ↑ Details emerge on Windows Kerberos vulnerability | ZDNet [online], www.zdnet.com [dostęp 2017-11-14] (ang.).
Linki zewnętrzne
[edytuj | edytuj kod]- Strona domowa projektu Kerberos
- The Kerberos FAQ
- Implementacja Heimdal protokołu Kerberos 5. pdc.kth.se. [zarchiwizowane z tego adresu (2006-03-14)].
- Shishi – wolna implementacja systemu Kerberos 5
- J. Kohl , C. Neuman , The Kerberos Network Authentication Service (V5), RFC 1510, IETF, wrzesień 1993, DOI: 10.17487/RFC1510, ISSN 2070-1721, OCLC 943595667 (ang.).
- M. Swift , J. Trostle , J. Brezak , Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols, RFC 3244, IETF, luty 2002, DOI: 10.17487/RFC3244, ISSN 2070-1721, OCLC 943595667 (ang.).
- K. Raeburn , Encryption and Checksum Specifications for Kerberos 5, RFC 3961, IETF, luty 2005, DOI: 10.17487/RFC3961, ISSN 2070-1721, OCLC 943595667 (ang.).
- K. Raeburn , Advanced Encryption Standard (AES) Encryption for Kerberos 5, RFC 3962, IETF, luty 2005, DOI: 10.17487/RFC3962, ISSN 2070-1721, OCLC 943595667 (ang.).
- C. Neuman i inni, The Kerberos Network Authentication Service (V5), RFC 4120, IETF, lipiec 2005, DOI: 10.17487/RFC4120, ISSN 2070-1721, OCLC 943595667 (ang.).
- L. Zhu , K. Jaganathan , S. Hartman , The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2, RFC 4121, IETF, lipiec 2005, DOI: 10.17487/RFC4121, ISSN 2070-1721, OCLC 943595667 (ang.).
- L. Zhu , B. Tung , Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), RFC 4556, IETF, czerwiec 2006, DOI: 10.17487/RFC4556, ISSN 2070-1721, OCLC 943595667 (ang.).
- L. Hornquist Astrand , T. Yu , Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos, BCP 179, RFC 6649, IETF, lipiec 2012, DOI: 10.17487/RFC6649, ISSN 2070-1721, OCLC 943595667 (ang.).