Secure Remote Password

Secure Remote Password (SRP) Protocol – protokół umożliwiający bezpieczne uwierzytelnienie jednej ze stron w drugim systemie, który ma kilka zalet w porównaniu do konwencjonalnych technik uwierzytelniania przy pomocy haseł:

  • Hasło nie jest przesyłane w jawnej postaci
  • Hasło nie jest przechowywane na serwerze w jawnej postaci
  • Nie jest możliwe odtworzenie haseł, ani powtórne logowanie przy pomocy danych przechwyconych z podsłuchiwanej komunikacji (nawet odszyfrowanej)
  • Jeśli klient zna prawidłowe hasło, a serwer odpowiednie dane, po przeprowadzeniu protokołu obie strony będą miały kryptograficznie silny klucz który można użyć np. do szyfrowania dalszej części ruchu
  • Nie jest możliwe podszywanie się pod dowolną ze stron w dowolnym momencie działania protokołu.

Algorytm bazuje na obliczeniowej trudności problemu logarytmu dyskretnego w ciałach skończonych. Jest on podobny w swej idei do protokołu Diffiego-Hellmana. Algorytm został opracowany na Uniwersytecie Standforda, między innymi przez Tom Wu. Pierwsze wersje protokołu pojawiły się w połowie lat 90, a we wrześniu roku 2000 opublikowano dokument RFC 2945 ↓ oraz RFC 2944 ↓ opisujące abstrakcyjny protokół oraz rozszerzenie protokołu Telnet używające go. Ulepszona wersja protokołu (SRP-6 oraz SRP-6a), umożliwiająca wymianę również pewnych dodatkowych stałych oraz zmniejszająca ilość komunikatów, została opublikowana w roku 2002. W listopadzie roku 2007 w dokumencie RFC 5054 ↓ opublikowano standard mechanizmu autoryzacji oparty na SRP-6 w protokole TLS. Przygotowywany dokument IEEE P1363.2 APKAS-SRP3 oraz SRP6 ma zajmować się standaryzacją protokołu.

Podobnie jak w standardowych mechanizmach autoryzacji przy pomocy hasła, na serwerze nie jest przechowywane hasło, a jedynie pewne wartości z niej wywiedzione. W porównaniu do szyfrowania opartego na certyfikatach, protokół SRP nie wymaga kosztownych certyfikatów w celu nawiązania bezpiecznej szyfrowanej komunikacji niezbędnej przy przesyłaniu jawnych haseł.

Poniżej przedstawiono kroki protokołu SRP-6a. Litera H oznacza poniżej kryptograficznie silną funkcję skrótu, taką jak SHA1. Symbol | oznacza konkatenację.

Przygotowanie

Pierwszy etap to przygotowanie odpowiednich wpisów na serwerze, jest to jedyny krok który wymaga jawnych haseł i powinien być wykonany w bezpieczny sposób (np. poprzez certyfikowany i zaszyfrowany kanał lub lokalnie bez użycia sieci komputerowej).

Wybierane, ustalane lub losowane:

  • N – duża (co najmniej 1000 bitów) liczba pierwsza, taka, że dla N = 2q+1, q jest również pierwsze
  • g – generator grupy skończonej o rozmiarze N

Obie wartości (zwane łącznie jako parametry grupy) są jawne.

Liczby te:

  • są losowane, sprawdzane czy spełniają powyższe warunki i umieszczane w bazie,
  • albo wybierane z wcześniej sprawdzonych par o odpowiedniej długości. Jest to możliwość zwykle bezpieczniejsza, ponieważ klient w pierwszej fazie protokołu dostanie powyższe liczby, a sprawdzenie czy spełniają one rzeczywiście wymienione właściwości może być zbyt złożone obliczeniowo aby przeprowadzać za każdym razem. Ich niespełnienie umożliwia łatwiejszy atak na protokół. W RFC 5054 ↓ znajdują się tabele zaufanych par o długościach od 1024 do 8192 bitów.

Następnie algorytm losuje:

  • s – dowolną dużą wartość, jest to wartość jawna, tzw. sól

Z tak wylosowanych danych, oraz nazwy użytkownika I oraz jego hasła P, są obliczane następujące wartości:

  • (tzw. verifier)

Następnie piątka (I, s (N, g), v) jest zapisywana w bazie danych (jeśli N i g są ustalone można je pominąć). Wartość x oraz P jest niszczona. Z tak przygotowanych danych nie da się łatwo odzyskać wartości P, z powodu:

  • z wartości v nie da się odtworzyć wartości x, ponieważ problem logarytmu dyskretnego wydaje się być trudny obliczeniowo

W przypadku gdyby było to możliwe (odtworzenie x), co prawda nadal nie jest możliwe odtworzenie P (funkcja H jest jednokierunkowa), ale znajomość x jest wystarczająca do złamania protokołu.

Dodatkowo w bazie można zapisać wartość

jednak nie jest to konieczne, ponieważ można ją obliczyć w samym protokole, czyni się to czasami z powodów wydajności.

Sam protokół bazuje na tych wartościach, i jest przedstawiony w dwóch wersjach poniżej (w zależności czy N i g są ustalone czy zmienne).

Protokół SRP-6a

Faza 1

1. Klient wysyła do serwera nazwę użytkownika I

2. Serwer sprawdza czy nazwa użytkownika jest prawidłowa. Serwer:

  • wczytuje wartości s, v oraz (N, g),
  • oblicza
  • losuje dużą (co najmniej 256 bitów) liczbę b (klucz prywatny serwera),
  • oblicza (klucz publiczny serwera),
  • wysyła do klienta wartości s, B oraz parę (N,g) (lub wartość ją opisującą).

Faza 2

3. Klient upewnia się, że N oraz g są bezpieczne. Klient:

  • upewnia się, że B mod N jest różne od zera,
  • oblicza
  • oblicza
  • oblicza
  • losuje dużą (co najmniej 256 bitów) liczbę a (klucz prywatny klienta)
  • oblicza (klucz publiczny klienta)
  • oblicza
  • oblicza
  • oblicza
  • wysyła A oraz M1 do serwera.

4. Serwer z otrzymanych wartości A oraz M1:

  • upewnia się, że A mod N jest różne od zera,
  • oblicza
  • oblicza
  • oblicza własne i porównuje zgodność z przesłanym. Jeśli M1 się nie zgadza oznacza to, że klient nie został uwierzytelniony i następuje zakończenie protokołu.
  • następnie oblicza
  • oblicza tajny klucz sesji
  • odsyła M2 do klienta.

Faza 3

5. Klient:

  • oblicza własne i porównuje zgodność z przesłanym
  • oblicza tajne

W tym miejscu obie strony posiadają wspólny silny klucz, który można użyć do szyfrowania ruchu. Klient nie znający hasła, lub serwer nie posiadający v nie są w stanie ich obliczyć.

W dalszej kolejności powinno się udowodnić poprawność kluczy:

6. Klient oblicz i wysyła na serwer.

7. Serwer oblicza swoje M, i porównuje poprawność. Następnie oblicza Z = H(A|M|K) i odsyła do klienta.

8. Klient oblicza swoje Z i sprawdza poprawność.

Modyfikacje

Algorytm posiada liczne modyfikacje, na przykład w trakcie obliczania M oraz Z można użyć funkcji HMAC w której K jest kluczem, zamiast zwykłej funkcji mieszającej.

Implementacje

Istnieją referencyjne implementacje protokołu SRP zaimplementowane przez autorów protokołu. Cisco (będące współautorem RFC 5054 ↓) oferuje produkty obsługujące SRP.

Jedną z niewielu bibliotek obsługujących rozszerzenia SRP protokołu TLS jest biblioteka GnuTLS[1]. Starszą wersję protokołu implementuje TLS Lite[2].

Wśród przeglądarek internetowych obsługę tego protokołu będzie wspierać prawdopodobnie Firefox 3.5[3]. Dodatkowo wśród nielicznych implementacji istnieje klient FTP IglooFTP Pro 3.9[4] oraz przeglądarka SupraBrowser[5]. GNU SSH implementuje SRP[6], oraz Kermit[7]. Istnieją również patche dla OpenSSH[8] oraz różne testowe implementacje w różnych językach programowania, takich jak PHP czy JavaScript[9].

Zobacz też

Przypisy

Linki zewnętrzne