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ę.

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:

• ${\displaystyle x=H(s|H(I|:|P))}$
• ${\displaystyle v=g^{x}\mod N}$ (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ść

• ${\displaystyle k=H(N|g)}$

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).

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 ${\displaystyle k=H(N|g),}$
• losuje dużą (co najmniej 256 bitów) liczbę b (klucz prywatny serwera),
• oblicza ${\displaystyle B=(k\cdot {}v+g^{b})\mod N}$ (klucz publiczny serwera),
• wysyła do klienta wartości s, B oraz parę (N,g) (lub wartość ją opisującą).

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

• upewnia się, że B \mod N jest różne od zera,
• oblicza ${\displaystyle k=H(N|g),}$
• oblicza ${\displaystyle x=H(s|H(I|:|P)),}$
• oblicza ${\displaystyle v=g^{x}\mod N,}$
• losuje dużą (co najmniej 256 bitów) liczbę a (klucz prywatny klienta)
• oblicza ${\displaystyle A=g^{a}\mod N}$ (klucz publiczny klienta)
• oblicza ${\displaystyle u=H(A|B)}$
• oblicza ${\displaystyle S=(B-k\cdot {}g^{x})^{(a+u\cdot {}x)}\mod N=(B-k\cdot {}v)^{(a+u\cdot {}x)}\mod N}$
• oblicza ${\displaystyle M1=H(A|B|S)}$
• 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 ${\displaystyle u=H(A|B),}$
• oblicza ${\displaystyle S=(A\cdot {}v^{u})^{b}\mod N,}$
• oblicza własne ${\displaystyle M1=H(A|B|S)}$ 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 ${\displaystyle M2=H(A|M1|S),}$
• oblicza tajny klucz sesji ${\displaystyle K=H(S),}$
• odsyła M2 do klienta.

5. Klient:

• oblicza własne ${\displaystyle M2=H(A|M1|S)}$ i porównuje zgodność z przesłanym
• oblicza tajne ${\displaystyle K=H(S),}$

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 oblicza ${\displaystyle M=H((H(N)\mathrm {xor} H(g))|H(I)|s|A|B|K)}$ 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ść.

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.

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].

• Protokół Diffiego-Hellmana

• http://srp.stanford.edu/
• T.T. Wu T.T., Telnet Authentication: SRP, RFC 2944, IETF, wrzesień 2000, DOI: 10.17487/RFC2944, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Wu T.T., The SRP Authentication and Key Exchange System, RFC 2945, IETF, wrzesień 2000, DOI: 10.17487/RFC2945, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Taylor D.D., T.T. Wu T.T., N.N. Mavrogiannopoulos N.N., T.T. Perrin T.T., Using the Secure Remote Password (SRP) Protocol for TLS Authentication, RFC 5054, IETF, listopad 2007, DOI: 10.17487/RFC5054, ISSN 2070-1721, OCLC 943595667  (ang.).