2007.08_Secure Remote Password Protocol.pdf

Secure Remote Password

Protocol

Obrona

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.

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

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

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

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.

hakin9 Nr 8/2007

www.hakin9.org

P rotokół Secure Remote Password

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

wszystkie znane metody ataku (m.in.

replay attack ).

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

kryptograicznych.

• SRP realizuje asymetryczną wy-

mianę kluczy, podobnie jak to ma

miejsce w protokole Difie-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-

ie-Hellman.

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, weryikator, sól).

Algorytm tworzenia takiej trójki

jest następujący:

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 kryptograii 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, identyikator 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 kryptograicznych.

Nawet w przypadku włamania i

• 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)),

• weryikator = v = gx % N.

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.

Tu kilka drobnych uwag. Nie musimy

używać akurat SHA, możemy użyć

dowolnej funkcji skrótu kryptogra-

icznego (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ę

weryikują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 weryikator). Zwracam

uwagę, że dwa konta z takim samym

hasłem nie będą miały takiej samej

liczby weryikującej.

Uwierzytelnienie w postaci kano-

nicznej wygląda następująco:

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 kryptograii 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

• klient wysyła do serwera prośbę

o sól dla podanego loginu,

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

loginu,

www.hakin9.org

hakin9 Nr 8/2007

Obrona

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

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/

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

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: cerekwicki@tlen.pl

x (x+ux)

) % ,

• klient oblicza Kklient = SHA-

(Sklient),

• serwer oblicza Sserwer=(A-v u b

ż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) modyi-

kacjami czy uproszczeniami tego pro-

tokołu. Przedstawione w tym tekście

wzory to szósta wersja tego protoko-

łu, przejrzana i zweryikowana przez

międzynarodowe środowisko nauko-

we zajmujące się kryptograią 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.

) ,

• 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 weryikuje 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 weryikuje 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ć.

Bezpieczeństwo

SRP jest tak bezpieczny, jak algo-

rytm Difie-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

Zwracam uwagę, że klient musi po-

kazać swój dowód jako pierwszy. Je-

śli jest on niepoprawny, serwer pod

hakin9 Nr 8/2007

www.hakin9.org

• 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

nie jest ujawniana. Dodatkowo K jest

kryptograicznie 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 kryptograicznej 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

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: