www.hakin9.org

hakin9 Nr 8/2007

62

Obrona

P

rotokół Secure Remote Password
(SRP) to najlepsze ze spotykanych roz-
wiązań, zapewniające wyższy poziom

bezpieczeństwa niż pozostałe konkurencyjne
metody oraz odporne na wszystkie, nawet naj-
groźniejsze, znane powszechnie sposoby prze-
prowadzania ataków.

Dowody z wiedzą zerową

W jaki sposób udowodnić komuś, że posia-
da się pewną wiedzę? Najprościej jest naj-
zwyczajniej ową wiedzę wyjawić. Gdyby jed-
nak wszyscy ludzie żyjący z dostarczania in-
formacji postępowali podobnie, wielu z nich nie
wyszłoby na tym zbyt dobrze i to nie tylko pod
względem finansowym. W ten sposób powsta-
ły różne metody przekonywania ludzi posiada-
jących pieniądze, że osoby deklarujące dobrą
znajomość określonej dziedziny wiedzy, na-
prawdę ją posiadają i chętnie dokonają wymia-
ny (np. uchylenie rąbka tajemnicy).

Matematycy nie zadowalają się półśrodka-

mi i problem ujęli dużo ściślej: jak komuś udo-
wodnić posiadanie pewnej wiedzy, bez zdra-
dzenia nawet jednego bitu tejże wiedzy czy na-
wet innych pośrednich faktów, pozwalających
na wywnioskowanie z nich wiedzy właściwej.

Problem ma wiele zastosowań praktycz-

nych, wśród których można wymienić kwestie
związane z protokołami uwierzytelniającymi
hasłem: jak klient ma udowodnić serwerowi, że
zna hasło, nie podając go explicite ani nawet w
postaci zaszyfrowanej (którą przecież można
teoretycznie złamać).

Krótko mówiąc, wymagamy, aby serwer

mógł być absolutnie pewny, że klient naprawdę
jest tym, za kogo się podaje, a jednocześnie po-
tencjalni podsłuchiwacze nie byli w stanie wy-
ciągnąć nic wartościowego z tej komunikacji.

Od protokołu opartego na tym założeniu

wymagamy dodatkowo, żeby był odporny na

Secure Remote Password

Protocol

Cezary G. Cerekwicki

stopień trudności

Najpopularniejszą techniką uwierzytelnienia jest użycie hasła.

Istnieje wiele rozwiązań, pozwalających zdalnie uwierzytelnić się

hasłem w relatywnie bezpieczny sposób, jednak każde z nich ma

swoje ograniczenia.

Z artykułu dowiesz się

• jak działa najbezpieczniejszy protokół uwierzy-

telniający przez użycie hasła,

• jak działają dowody z wiedzą zerową.

Co powinieneś wiedzieć

• wskazane jest rozumienie podstaw terminologii

kryptologicznej i elementarna znajomość mate-
matyki.

Najlepszy istniejący protokół zdalnego uwierzytelniania przy użyciu hasła

hakin9 Nr 8/2007

www.hakin9.org

63

wszystkie znane metody ataku (m.in.

replay attack).

Secure Remote

Password

Secure Remote Password (SRP) to
nowoczesny protokół uwierzytelnia-
jący, stworzony przez ludzi świado-
mych wszystkich publicznie znanych
technik atakowania tego typu proto-
kołów:

• SRP zapewnia uwierzytelnie-

nie obu stron; serwer może być
pewny, że klient zna hasło, a
klient ma gwarancję, że serwer
jest tym samym, na którym za-
kładano konto.

• SRP ma charakter dowodu z wie-

dzą zerową; nawet jeśli komuni-
kacja będzie się odbywała kana-
łem nieszyfrowanym, potencjalni
podsłuchiwacze nie będą w stanie
nic sensownego wywnioskować.
Oczywiście zaszyfrowanie kanału
(np. poprzez SSL) wprowadzi do-
datkowy poziom bezpieczeństwa.

• SRP, w przeciwieństwie do więk-

szości metod kryptografii klucza
publicznego, nie wymaga istnie-
nia zaufanego trzeciego podmio-
tu, który ręczyłby za tożsamość
stron.

• SRP jest całkowicie odporny na

ataki słownikowe online, zarówno
ze strony aktywnych, jak i pasyw-
nych podsłuchiwaczy. W przypad-
ku pozytywnego uwierzytelnienia,
SRP pozostawia obu stronom uni-
kalny, trudny do przewidzenia i dla
każdej sesji inny klucz prywatny,
który może być użyty do zabezpie-
czenia sesji (np. jako zalążek ge-
neratora liczb pseudolosowych dla
szyfru strumieniowego, klucz szy-
fru blokowego, identyfikator sesji).

• SRP zapewnia duże bezpieczeń-

stwo nawet w przypadku uży-
cia słabych haseł (krótkich, ma-
ło skomplikowanych).

• SRP jest tak skonstruowany, że

wymusza składowanie haseł w
systemie w sposób bardzo bez-
pieczny, tzn. w postaci saltowa-
nych hashy, czyli zrandomizowa-
nych skrótów kryptograficznych.
Nawet w przypadku włamania i

kradzieży pliku z hasłami, przed
włamywaczem stoi jeszcze ko-
nieczność przeprowadzenia ata-
ku brutalnego lub słownikowe-
go, bez możliwości użycia obli-
czonych wcześniej tablic skrótów
kryptograficznych.

• SRP realizuje asymetryczną wy-

mianę kluczy, podobnie jak to ma
miejsce w protokole Diffie-Hell-
man.

• SRP nie jest rozwiązaniem opa-

tentowanym ani krępowanym re-
strykcyjną licencją. Gotowe im-
plementacje są dostępne w sie-
ci jako open source.

• SRP jest dość szybkim protoko-

łem (zważywszy na jakość ofe-
rowanego bezpieczeństwa), co
ważne, jest on szybszy niż Dif-
fie-Hellman.

Wersja szósta SRP jest standardem
ISO/IEC 11770-4. Używana jest ja-
ko silne uwierzytelnienie w protoko-
łach SSL/TLS, EAP, SAML. Są też
implementacje FTP, SSH czy telnetu
wykorzystujące SRP. SRP ma bez-
pieczniejszy mechanizm uwierzytel-
niający od natywnego SSH.

Podsumowując, mamy do czy-

nienia z potężnym narzędziem, za-
pewniającym bardzo silne bezpie-
czeństwo.

Jak to działa?

Na początek krótkie wprowadzenie.
Jak wiadomo, liczby pierwsze to takie
liczby, które mają dokładnie dwa róż-
ne dzielniki: samą siebie i jedynkę.
W kryptografii mają znaczenie także
tzw. liczby pierwsze Sophie Germain
oraz bezpieczne liczby pierwsze.

Jeśli liczba l postaci l = 2p + 1,

gdzie p jest liczbą pierwszą, również
jest liczbą pierwszą, to p jest licz-
bą pierwszą Sophie Germain, nato-
miast liczba l jest bezpieczną liczbą
pierwszą.

W algorytmach protokołu SRP

będziemy się posługiwać arytmety-

ką modulo N. Liczba N musi być zna-
ną obu stronom bezpieczną liczbą
pierwszą (musi też być odpowiednio
duża, im większa tym lepsza). Zakła-
damy sobie również stałą g, zwaną
generatorem. Najczęściej przyjmuje

się g = 2. Kolejną tego typu stałą jest

k, w SRP-6a należy ją obliczyć z ta-
kiego wzoru: k = SHA(N | g). Znak
„|” oznacza konkatenację (sklejanie)
ciągu znaków.

Wszystkie trzy stałe (N, g, k) są

ustalone odgórnie i publicznie znane
(przynajmniej obu stronom, ale mogą
też być bez najmniejszego ryzyka zna-
ne potencjalnemu włamywaczowi).

Aby móc stosować protokół

SRP, konta użytkowników powinni-
śmy przechowywać w postaci trójek
(login, weryfikator, sól).

Algorytm tworzenia takiej trójki

jest następujący:

• sól = random() (tu uwaga: im

wyższa wartość random w przy-
padku danej liczby, tym bezpiecz-
niejszy będzie protokół. Zdecydo-
wanie sugeruję użycie czegoś w
rodzaju /dev/random albo samo-
dzielnej implementacji podobne-
go mechanizmu),

• x = SHA(sól | SHA(login | „:” | ha-

sło)),

• weryfikator = v = gx % N.

Tu kilka drobnych uwag. Nie musimy
używać akurat SHA, możemy użyć
dowolnej funkcji skrótu kryptogra-
ficznego (byle dobrej) nie zmieniając
zasadniczych własności protokołu
(oczywiście pod warunkiem, że bę-
dziemy jej używać konsekwentnie).
Poprzez „hasło” rozumiemy ciąg re-
prezentujący hasło w postaci jawnej.
Znak „%” należy rozumieć jako mo-

dulo (czyli reszta z dzielenia).

Jak widzimy, nie będziemy prze-

chowywać haseł w postaci jawnej.
Przechowujemy jawny login, liczbę
weryfikującą (w dalszej części tekstu
będziemy o nim mówić jako o zmien-
nej v) oraz sól (materiał losowy ran-
domizujący weryfikator). Zwracam
uwagę, że dwa konta z takim samym
hasłem nie będą miały takiej samej
liczby weryfikującej.

Uwierzytelnienie w postaci kano-

nicznej wygląda następująco:

• klient wysyła do serwera prośbę

o sól dla podanego loginu,

• serwer wysyła sól dla żądanego

loginu,

hakin9 Nr 8/2007

www.hakin9.org

Obrona

64

• klient oblicza a = random() (po-

nownie podkreślam istotność so-
lidnej losowości; a musi też być
większe od

log

g

N

),

• klient oblicza

A=g

N

a

%

,

• klient wysyła serwerowi obliczo-

ną liczbę A,

• jeśli A = 0 % N, serwer powinien

się rozłączyć,

• serwer oblicza b = random() (b

musi być większe od

log

g

N

),

• serwer oblicza i wysyła

B kv+g

N

g

b

%

,

• jeśli B = 0 % N, klient powinien

się rozłączyć,

• obie strony obliczają u = SHA

(A | B),

• klient oblicza x = SHA(sól | SHA-

(login | „:” | hasło)),

• klient oblicza

Sklient=(B-kg

N

x (x+ux)

)

%

,

• klient oblicza Kklient = SHA-

(Sklient),

• serwer oblicza

Sserwer=(A-v

u b

)

,

• serwer oblicza Kserwer = SHA-

(Sserwer).

W tym momencie, obie strony mają
klucz sesji K, który powinien być taki
sam (wówczas uwierzytelnienie się
powiodło). Jak bezpiecznie spraw-
dzić, czy uwierzytelnienie się powio-
dło? Można to zrobić na kilka sposo-
bów, na przykład tak:

• klient wysyła M1 = SHA(SHA(N)

xor SHA(g) | SHA(login) | sól | A |
B | Kklient),

• serwer weryfikuje M1, obliczając

je w analogiczny sposób (oczy-
wiście Kklient powinno być rów-
ne Kserwer). Jeśli M1 obliczone
przez serwer różni się od przeka-
zanego od klienta, uwierzytelnie-
nie klienta jest nieudane. Serwer
musi się rozłączyć,

• serwer wysyła M2 = SHA(A | M1 |

Kserwer),

• serwer weryfikuje M2, obliczając

je w analogiczny sposób. Jeśli M2
obliczone przez klienta jest różne
od przekazanego przez serwer,
uwierzytelnienie serwera jest nie-
udane. Klient powinien się rozłą-
czyć.

Zwracam uwagę, że klient musi po-
kazać swój dowód jako pierwszy. Je-
śli jest on niepoprawny, serwer pod

żadnym pozorem nie może pokazy-
wać swojego dowodu!

W niektórych opracowaniach moż-

na zobaczyć inne formuły wzajemne-
go uwierzytelnienia, w szczególności
chodzi tu o to, że M1 może być wyli-
czone szybciej (można ze wzoru wy-
rzucić N, g, login i sól). Tym niemniej
jest przynajmniej jeden dobry powód,
dla którego warto zostawić te dodat-
kowe obliczenia: w przypadku ataku
brutalnego atakujący będzie miał trzy
wywołania SHA więcej na iterację,
co w skali takiego ataku oznacza bar-
dzo poważny koszt obliczeniowy. Nie-
pokoić może duża liczba wymian da-
nych między serwerem i klientem. W
rzeczywistości można ją nieco zredu-
kować łącząc niektóre komunikaty (w
tabeli 1 zawarty jest zoptymalizowa-
ny schemat wymiany komunikatów).
Można posłużyć się też (w przypadku
aplikacji webowych) technikami AJAX,
aby konwersacja klienta z serwerem
była niezauważalna dla użytkownika.

Zmienna u może być losowa, ale

wówczas jedna strona musi się nią po-
dzielić z drugą (oczywiście lepiej jest,
gdy losowanie przeprowadzi serwer).
Dodatkowo u nie może być równe ze-
ro (modulo N oczywiście), zatem je-
śli u będzie losowane, strona która je

otrzyma, musi sprawdzić jego niezero-
wość modulo N i ewentualnie się roz-
łączyć. Przestrzegam przed nieprze-
myślanymi (czytaj: nie poprzedzonymi
głębokim zrozumieniem istotności każ-
dej zmiennej i każdego kroku) modyfi-
kacjami czy uproszczeniami tego pro-
tokołu. Przedstawione w tym tekście
wzory to szósta wersja tego protoko-
łu, przejrzana i zweryfikowana przez
międzynarodowe środowisko nauko-
we zajmujące się kryptografią i bez-
pieczeństwem informacyjnym. Każda
użyta zmienna i każde przekształcenie
ma swoją rolę do odegrania i bynajm-
niej nie są one przypadkowe. Zdecy-
dowanie radzę używać gotowych im-
plementacji, a gdy jest to niemożliwe,
własną implementację poprzedzić do-
kładną lekturą publikacji dostępnych
na stronie podanej w ramce.

Bezpieczeństwo

SRP jest tak bezpieczny, jak algo-
rytm Diffie-Hellman, a więc bezpie-
czeństwo protokołu zależy od trud-
ności liczenia logarytmów dyskret-
nych oraz od nieodwracalności uży-
tej funkcji skrótu.

Przez sieć nie jest przesyłane ani

hasło, ani wyliczona wartość x. Żad-
na użyteczna informacja o kluczu K

Tabela 1.

Zoptymalizowany schemat komunikatów w protokole SRP

Klient

Kierunek komunikatu Serwer

A, login

>
<

B, sól

M1

>
<

M2

W Sieci

Na tej stronie znajduje się kalkulator SRP, pozwalający podejrzeć wartości wszystkich
zmiennych pomocniczych oraz eksperymentować z różnymi wartościami wejściowymi.
http://srp.stanford.edu/demo/demo.html
To jest strona domowa projektu SRP. http://srp.stanford.edu/

O autorze

Autor jest z wykształcenia informatykiem i politologiem. Pracował jako programista,
administrator, konsultant, tłumacz, koordynator międzynarodowych projektów, dzien-
nikarz i publicysta. Pisał programy w dziesięciu językach programowania (od asem-
blerów po języki skryptowe), w czterech systemach operacyjnych, na dwóch platfor-
mach sprzętowych.
Kontakt z autorem: [e-mail]

nie jest ujawniana. Dodatkowo K jest
kryptograficznie silne, w przeciwień-
stwie do zazwyczaj mało złożonych
haseł. W efekcie próba odgadnięcia
K poprzez atak brutalny jest z gó-
ry skazana na porażkę. Wymienia-
ne przez sieć liczby (sól, A, B, M1
i M2) są dość duże (co ich odgady-
wanie czyni bardzo trudnym), a wy-
wnioskowanie z nich istotnych warto-
ści poprzez odwrócenie działań ma-
tematycznych prowadzi do odwraca-
nia kryptograficznej funkcji skrótu lub
liczenia logarytmu dyskretnego du-
żej losowej liczby (oba te zadania są
obecnie bardzo trudne).

Atak typu man-in-the-middle nie

może być przeprowadzony przez ko-
goś, kto nie zna hasła.

Jeśli użyty w przeszłości klucz

sesji zostanie skompromitowany, nie
grozi to ujawnieniem używanego ha-
sła. Jeśli włamywacz wykradnie ha-
sło, nie będzie w stanie przy jego po-
mocy odgadnąć kluczy poprzednich
sesji. Protokół pozostaje bezpiecz-
ny, nawet jeśli jedna ze stron nie jest
tym, za kogo się podaje.

Aktywny intruz, mający możli-

wość generowania komunikatów
podszywających się pod strony ko-
munikacji, nie jest w stanie przejąć
sesji. Jedyne, co może zrobić, to
przeprowadzić banalny atak typu de-

nial-of-service, tzn. może doprowa-
dzić do nieudanego uwierzytelnienia
legalnego użytkownika. Ale akurat
tego typu akty prymitywnego wanda-
lizmu prawie zawsze są możliwe.

Podsumowanie

SRP jest obecnie szczytowym osią-
gnięciem w dziedzinie protokołów
uwierzytelniających hasłem w spo-
sób możliwie bezpieczny. Łatwość
implementacji, oraz dostępne gotowe
biblioteki czynią to rozwiązanie dość
prostym do wdrożenia w nowych sys-
temach (przeróbka systemu o innej
technice uwierzytelniania może być
znacznie bardziej kłopotliwa).

Możemy sobie życzyć, aby tego

typu rozwiązania były jak najszerzej
wykorzystywane, zwiększając su-
mę bezpieczeństwa informacyjnego
używanych przez nas systemów. l