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:

• $x=H(s|H(I|:|P))$
• $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ść

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

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 $k=H(N|g),$
• losuje dużą (co najmniej 256 bitów) liczbę b (klucz prywatny serwera),
• oblicza $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ą).

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

Faza 3

5. Klient:

• oblicza własne $M2=H(A|M1|S)$ i porównuje zgodność z przesłanym
• oblicza tajne $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 $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ść.

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. Starszą wersję protokołu implementuje TLS Lite.

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

Zobacz też

• Protokół Diffiego-Hellmana

Linki zewnętrzne

• 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. i inni, 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.).