– 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 oraz 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 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: – duża (co najmniej 1000 bitów) liczba pierwsza, taka, że dla = 2+1, jest również pierwsze – generator grupy skończonej o rozmiarze

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 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 oraz jego hasła , są obliczane następujące wartości:

(tzw. )

Następnie piątka (, (, ), ) jest zapisywana w bazie danych (jeśli i są ustalone można je pominąć). Wartość oraz jest niszczona. Z tak przygotowanych danych nie da się łatwo odzyskać wartości , z powodu: z wartości nie da się odtworzyć wartości , ponieważ problem logarytmu dyskretnego wydaje się być trudny obliczeniowo W przypadku gdyby było to możliwe (odtworzenie ), co prawda nadal nie jest możliwe odtworzenie (funkcja jest jednokierunkowa), ale znajomość 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 i są ustalone czy zmienne).

Protokół SRP-6a Faza 1 1. Klient wysyła do serwera nazwę użytkownika

2. Serwer sprawdza, czy nazwa użytkownika jest prawidłowa. Serwer: wczytuje wartości , oraz (, ), oblicza losuje dużą (co najmniej 256 bitów) liczbę (klucz prywatny serwera), oblicza (klucz publiczny serwera), wysyła do klienta wartości , oraz parę (,) (lub wartość ją opisującą).

Faza 2 3. Klient upewnia się, że oraz są bezpieczne. Klient: upewnia się, że \mod jest różne od zera, oblicza oblicza oblicza losuje dużą (co najmniej 256 bitów) liczbę (klucz prywatny klienta) oblicza (klucz publiczny klienta) oblicza oblicza oblicza wysyła oraz do serwera.

4. Serwer z otrzymanych wartości oraz : upewnia się, że \mod jest różne od zera, oblicza oblicza oblicza własne i porównuje zgodność z przesłanym. Jeśli 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 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 nie są w stanie ich obliczyć.

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

6. Klient oblicza i wysyła na serwer.

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

8. Klient oblicza swoje i sprawdza poprawność.

Modyfikacje Algorytm posiada liczne modyfikacje, na przykład w trakcie obliczania oraz można użyć funkcji HMAC w której 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 ) oferuje produkty obsługujące SRP.

Jedną z niewielu bibliotek obsługujących rozszerzenia SRP protokołu TLS jest biblioteka GnuTLSAuthentication using SRP – GNU TLS 2.8.5.. Starszą wersję protokołu implementuje TLS LiteTLS Lite | Get TLS Lite at SourceForge.net..

Wśród przeglądarek internetowych obsługę tego protokołu będzie wspierać prawdopodobnie Firefox 3.5Firefox/3.next/hitlist – MozillaWiki.. Dodatkowo wśród nielicznych implementacji istnieje klient FTP IglooFTP Pro 3.9. oraz przeglądarka SupraBrowserSupraBrowser | Get SupraBrowser at SourceForge.net.. GNU SSH implementuje SRPLSH – a GNU implementation of the Secure Shell protocols., oraz KermitThe Kermit Project – Columbia University: Secure Scriptable Telnet, FTP, SSH Terminal Emulation and File Transfer Clients.. Istnieją również patche dla OpenSSHOpenSSH SRP patch | OpenSSH SRP patch at SourceForge.net. oraz różne testowe implementacje w różnych językach programowania takich jak PHP czy JavaScriptTiny SRP | Tiny SRP at SourceForge.net..

Zobacz też Protokół Diffiego-Hellmana

Przypisy

Linki zewnętrzne http://srp.stanford.edu/

Kategoria:Uwierzytelnienie Kategoria:Protokoły kryptograficzne