Jeżeli kiedykolwiek płaciłeś kartą kredytową poprzez Internet, najprawdopodobniej transmisja danych przebiegała za pośrednictwem protokołu SSL (ang. Secure Socket Layer). Jest on głównie używany do tego by w trakcie przeprowadzania operacji finansowych użytkownicy mogli czuć się bezpiecznie. Transakcje przy użyciu SSL przebiegają szybko i przezroczyście dla użytkownika.
SSL jest protokołem służącym do wymiany danych spełniającym trzy warunki ochrony informacji: integralność informacji, uwierzytelnianie oraz poufość, dostarczając bezpiecznej wymiany kluczy pomiędzy przeglądarką internetową i serwerem. Należy odnotować, że SSL nie spełnia zasady niezaprzeczalności.
Użytkownicy mogą w łatwy sposób zauważyć czy używają SSL-a. O jego obecności świadczy widok małej kłódki w przeglądarce internetowej.
Postaram się przedstawić opis biblioteki SSL/TLS wchodzącej w skład projektu OpenSSL. Lecz zanim to nastąpi, starym zwyczajem chciałbym przedstawić historię oraz zasadę działania tego protokołu.
Historia SSL-a.
SSL powstał w 1994 za sprawą Netscape. Jednocześnie, Microsoft wymyślił PCT (ang. Private Communicating Technology) jako konkurencje dla SSL-a. Wymusiło to na Netscape zrealizowanie SSL w wersji 3 (SSL v3) w 1995 roku.
W 1996 roku za sprawą IETF (ang. Internet Engineering Task Force) powstała grupa robocza TLS (ang. Transport Layer Security), która ma za zadanie rozwijać oraz publikować standard SSL. W styczniu 1999 roku grupa ta opublikowała protokół TLS, który bazuje na SSL v3. Ważny jest fakt, że Microsoft oraz Netscape wspierają TLS. Microsoft oraz Netscape zaimplementowały TLS w swoich przeglądarkach.
Ogólny opis sesji SSL.
Hello (i negocjacja parametrów kryptograficznych)
Klient: Hello, serwer. Porozmawiajmy. Proszę, przyślij mi swój klucz publiczny.
Serwer: Przesyła klientowi swój certyfikat.
Klient: Szyfruje losowy numer za pomocą klucza publicznego serwera i przesyła do serwera.
Uzgadnianie klucza:
Klient i Serwer: Użycie losowego numeru do niezależnego generowania dzielonych tajnych kluczy (ang. secret keys).
Klient uwierzytelnia serwer:
Serwer: Serwer udowadnia klientowi, że wygenerował identyczny tajny klucz jak klient.
Poufność i integralność:
Klient i Serwer: Używają tajnych kluczy do wymiany wiadomości.
Pierwszą rzeczą jaką muszą zrobić uczestnicy biorący udział w sesji SSL/TLS jest negocjacja parametrów kryptograficznych, ponieważ przy pierwszym połączeniu ich nie znają. Warto zauważyć również to, że to klient uwierzytelnia serwer, a nie odwrotnie.
Szczegółowy opis sesji SSL.
Ponieważ SSL/TLS może używać różnych wariacji systemów kryptograficznych, dla uproszczenia w przykładzie użyję tylko jednej z nich.
Hello i negocjacja parametrów:
KLIENT:
?Hello
?Możemy porozmawiać użwyjąc:
1.Wersja: TLS v1, jeśli go znasz, jeżeli nie to użyjmy SSL v3
2.Wymiana klucza: RSA, jeśli znasz, jeżelu nie to użyjmy Diffie-Hellman
3.Metoda szyfrowania tego klucza: Potrójny DES jeśli możesz, jeżeli nie to DES
4.Skrót wiadomości (ang. hash): SHA-1 jeśli możesz, jeżli nie to MD5
5.Metoda kompresji danych: PKZip jeśli możesz, jeżeli nie to gzip
6.Losowy numer: 192,201,083
SERWER:
?Słyszę Cię porozmawiajmu używając:
1.Wersja: TLS v1
2.Wymiana klucza: RSA
3.Metoda szyfrowania tego klucza: DES
4.Skrót wiadomości (ang. hash): SHA-1
5.Metoda kompresji danych: PKZip
6.Losowy numer: 823,495,127
Jako metody szyfrowania tajnego klucza nie można używać na razie Rijndael’a ponieważ jest ciągle zbyt nowy. RSA (Rivest – Shamir – Adleman) jest systemem kryptograficznym opartym na kluczu asymetrycznym. Opracowany został w 1977 roku przez Rona Rivesta, Adi Shamira oraz Leonarda Adlemana. Prawa do algorytmu RSA posiada firma RSA Security Inc., (www.rsasecurity.com) udzielająca płatnej licencji na jego używanie w programch innych producentów (patent ważny jednak tylko w USA).
Fundamentem RSA jest algorytm służący do generowania unikalnych i bezpiecznych (odpornych na próby odgadnięcia) par kluczy. Mnoży on dwie duże liczby liczby pierwsze i z otrzymanego wyniku poprzez kilka innych dodatkowych operacji ustala klucz publiczny i zależny od niego klucz prywatny. Pierwszy z nich służy do szyfrowania wiadomości przeznaczonych dla właściciela kluczy i co za tym idzie powinien być jak najszerzej propagowany. Klucz prywatny jest tajny i tylko przy jego pomocy można odszyfrować to, co zostało zakodowane kluczem publicznym.
Diffie – Hellman jest pierwszym algorytmem realizującym w praktyce ideę kryptografii asymetrycznej. Jego nazwa również pochodzi od nazwisk twórców. Jest on uważany za algorytm bezpieczny – pod warunkiem stsosowania długich kluczy. Konstrukcja algorytmu oparta jest na matematycznym problemie logarytmów dyskretnych, pod względem trudności porównywalnych z problemem rozkładu dużych liczb pierwszych (patrz algorytm RSA). – więcej: http://www.ietf.org/rfc/rfc2631.txt
DES (Data Encryption Standard) jest jednym z najpopularniejszych algorytmów szyfrowania danych (kryptosystemów). Opracowano go w latach siedemdziesiątych w firmie IBM, w ramach konkursu na opracowanie efektywnego kryptosystemu na potrzeby rządu Stanów Zjednoczonych. Po drobnych modyfikacjach wprowadzonych przez NSA (National Security Agency – Narodowa Agencja Bezpieczeństwa), w 1977 roku DES został uznany przez rząd USA za oficjalny standard.
Zasada działania opiera się na 56-bitowym tajnym kluczu, który wykorzystywany jest do kodowania 64-bitowych bloków danych. Operacja przebiega w kilku-kilkunastu etapach, podczas których tekst wiadomości ulega wielokrotnym przeobrażeniom. Oczywiście klucz ten musi być znany zarówno nadawcy jak i odbiorcy.
Na początku 1997 roku, firma RSA Data Security ustanowiła nagrodę w wysokości 10 000 USD za złamanie algorytmu DES. Połączenie wysiłku naprędce powołanej grupy oraz wolnych mocy 14 000 komputerów użytkowników Internetu, zaowocowało złamaniem kodu 90-go dnia trwania projektu.
Próby ratowania pozycji DES na rynku poskutkowały opracowaniem algorytmu 3DES (Triple-DES, potrójny DES). Dzięki wprowadzeniu operacji trzykrotnego użycia trzech różnych kluczy o długości 56 bitów, czas na złamanie zaszyfrowanej wiadomości wydłuża się z kilku dni do bilionów lat. Więcej: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf.
Algorytm MD5, (dokument: RFC1321) (ang. message digest algorithm), przypuszczalnie najpopularniejsza funkcja haszująca (4 etapy, 16 kroków) autorstwa R. Rivesta, stosowana do uwierzytelniania komunikatów i tworzenia podpisów cyfrowych przez wykonywanie streszczeń komunikatów. Nieobalona hipoteza głosi, że znalezienie dwóch takich samych streszczeń komunikatów uzyskanych w MD5 wymagałoby 264 operacji, a liczba operacji potrzebnych do znalezienia komunikatu o danym skrócie jest rzędu 2128. Algorytm MD5 ma prostszego poprzednika (3 etapy) w postaci algorytmu MD4 (dokument: RFC1320) z 1992.
Algorytm SHA (Secure Hash Algorithm), podobny do MD5 algorytm rozpraszający stosowany w podpisach cyfrowych, opracowany w NIST (National Institute of Standards and Technology) jako federalny standard przetwarzania informacji (FIPS PUB 180) w 1993.
Algorytm SHA przetwarza w blokach 512-bitowych dane wejściowe o długości mniejszej niż 264 bitów, dając streszczenie komunikatu mające 160 bitów. Odtworzenie komunikatu metodą „brutalną” wymagałoby liczby prób rzędu 2160. Więcej: .
Wymiana certyfikatów
Po udzieleniu odpowiedzi klientowi na Hello, serwer wysyła swój certyfikat. Certyfikat serwera podpisany jest przez zaufany ośrodek jakim może być urząd ds. certyfikatów (CA). Klient weryfikuje certyfikat serwera za pomocą klucza publicznego udostępnionego przez CA.
Po tym jak serwer wysyła swój certyfikat, protokół SSL/TLS zezwala na to by zażądał od klienta jego certyfikatu. Nie jest jednak wymagane to by serwer żądał certyfikatu klienta i nawet jeśli serwer go zażąda klient nie musi go wysyłać. Później wytłumaczę dlaczego.
Uzgadnianie klucza (Wymiana)
Klient generuje 48 bajtową losową wartość (pre-master secret). Szyfrowana ona jest za pomocą klucza publicznego (RSA) serwera. Następnie serwer odszyfrowuje tą wartość używając swojego dobrze dobranego klucza prywatnego RSA. Do tej pory we wszystkich przykładach wymiany tajnego klucza pokazywano, że obie strony dzielą tylko jeden tajny klucz. W prawdziwych systemach preferowane jest używanie większej ilości tajnych kluczy by utrudnić kryptoanalizę.
Serwer generuje 3 tajne klucze dla wiadomości przesyłanych od serwera do klienta. Pierwszy klucz (taki jak tajny klucz DES) służy do odszyfrowania, drugi klucz do integralności wiadomości (HMAC), i trzeci klucz jest używany do zainicjalizowania szyfru (IV). Klucze te są używane tylko dla wiadomości przesyłanych od serwera do klienta, a nie odwrotnie. Serwer generuje trzy dodatkowe klucze dla wiadomości przesyłanych od klienta do serwera. Podobnie jak serwer klient także musi wygenerować dokładnie takie same klucze.
Metoda HMAC (Hashed Message Authentication Code) używana jest do tworzenia niepowtarzalnego kodu uwierzytelniającego wiadomości, obliczanego z użyciem generatora skrótów i klucza prywatnego. Metoda HMAC powiększa moc istniejących generatorów skrótów do poziomu gwarantującego ich odporność na ataki nawet wówczas, gdy generator w oryginalnej postaci może zostać złamany (więcej informacji na temat tej metody zawiera specyfikacja RFC 2104). Więcej: ftp://sunsite.icm.edu.pl/pub/doc/rfc/rfc2104.txt.
Uwierzytelnienie
Jesteśmy w miejscu w którym możesz spodziewać się, że to serwer będzie sprawdzał autentyczność klienta, ale w naszym przykładzie tak nie jest.
Są ku temu dwa ważne powody:
Po pierwsze, serwer i tak będzie sprawdzał kartę kredytową klienta, a sprawdzanie autentyczności klienta może zabrać trochę czasu (usprawnienie dla niecierpliwych klientów).
Po drugie, większość klientów e-commerce nie posiada jeszcze swoich certyfikatów, a przyjmowanie nieznanych i tak wiązałoby się z dużym ryzykiem.
Klient przesyła do serwera wiadomość zaszyfrowaną za pomocą wspólnych tajnych kluczy. Wiadomość ta, nazywana końcowym uzgodnieniem (ang. finished handshake) jest jako pierwsza szyfrowana tajnym kluczem.
Serwer odpowiada również podobnym komunikatem. Klient jest teraz zapewniony, że musi komunikować się z serwerem ponieważ klient przesłał wiadomość: pre-master secret zaszyfrowaną za pomocą za pomocą klucza publicznego RSA serwera. Serwer odszyfrowuje tą wiadomość by obliczyć sześć wspólnych tajnych kluczy.
Poufność i integralność
?Kolejne kroki serwera potrzebne do przeprowadzenia bezpiecznej wymiany wiadomości, za pomocą poprzednich etapów:
1.Serwer kompresuje wiadomość korzystając z uzgodnionej metody kompresji,
2.Serwer haszuje (ang. hash) skompresowane wiadomości i klucz HMAC tworząc HMAC,
3.Serwer szyfruje kombinację HMAC i spakowanych wiadomości za pomocą klucza DES (od serwera do klienta).
?Klient otrzymuje zaszyfrowną wiadomość i odwraca cały proces:
1.Klient odszyfrowuje kombinację HMAC i spakowanych wiadomości używając jego kopii klucza DES (od serwera do klienta),
2.Klient uwierzytelnia wiadomość w dwóch krokach. Po pierwsze, haszuje odszyfrowane spakowane dane z kluczem HMAC. Potem porównuje HMAC z kroku 1 z HMAC uzyskanym z haszowania.
3.Klient odkompresowuje i odzyskuje tekst jawny.
Rodzaje protokołu TLS
W poprzednim przykładzie klient przesłał wygenerowaną losowo 48 – bajtową wartość zwaną poprzednikiem tajnego klucza (ang. pre-master secret) szyfrując ją za pomocą publicznego klucza serwera RSA. Po tym jak serwer odszyfruje tą wartość używając swojego klucza prywatnego, tylko serwer i klient wiedzą jak użyć poprzednika tajnego klucza do wygenerowania sześciu dzielonych tajnych kluczy.
Protokół SSL/TLS pozwala również na użycie szyfru Diffie-Hellmana do niezależnego stworzenia dzielonej wartości pre-master secret oraz sześciu dzielonych tajnych kluczy.
Anonimowy Diffie-Hellman (ang. Anonymous Diffie-Hellman).
Jedna z odmian szyfru, zwana anonimowym Diffie-Hellmanem, pozwala serwerowi oraz klientowi na równoczesne generowanie sześciu dzielonych tajnych kluczy bez uwierzytelniania drugiej strony. Ale wtedy ani serwer ani klient nie jest pewny z kim ma doczynienia po drugiej stronie połączenia. Nasuwa się pytanie, po co zatem ktoś chce zastosować takie podejście ?
Jak już powiedziałem, strona serwera jest często zadowolona, kiedy otrzyma numer karty kredytowej i jest także chętna do podjęcia ryzyka jeżeli ktoś jeszcze używa karty kredytowej klienta bez jego uwierzytelnienia.
Co możemy powiedzieć o stronie klienta ? Klient może podjąć decyzję by zaufać, że serwer z którym się łączy jest tym którego on ma na myśli. Być może nie jest to wielkie ryzyko. Ludzie często dają numer karty kredytowej nieznajomym przez telefon, w restauracji itd. Więc czemu nie skorzystać także i z tej drogi ? Cóż, większość z nas tak robi.
Ale jeśli chcemy wysłać przez Internet bardziej wartościowe dane np. hasło, informacje na temat zdrowia, sposób z użyciem szyfru anonimowego Diffie-Hellmana jest zły.
Stały i ulotny Diffie-Hellman (ang. Fixed and Ephemeral Diffie-Hellman).
Oba rodzaje szyfru Diffie-Hellmana zawierają uwierzytelnienie. W stałym (statycznym) Diffie-Hellmanie serwer oraz klient wymieniają publiczne wartości zaszyfrowane Diffie-Hellmanem używając zaufanych certyfikatów. W odmianie ulotnej szyfru, serwer oraz klient wymieniają publiczne wartości Diffie-Hellmana podpisane za pomocą kluczy RSA lub DSA.
Porównanie protokołów TLS, SSL v3 i SSL v2.
W standardzie TLS jest napisane, że „wersja 1.0 protokołu TLS i SSL v3 są bardzo podobne i użycie obu jest równie łatwe”. Kilka różnic dotyczy drobnych zmian w obliczeniach HMAC, wsparcia co do uzgodnienień wyboru szyfrów użytych w transmisji (ang. cipher suite) oraz obliczeniach losowej wartości. Możesz traktować TLS jako protokół „SSL v3.1”.
Różnice pomiędzy SSL v3 a SSL v2 są już wyraźne. Ten kto ma dostęp do SSL v3 nie powinien używać SSL v2. Użytkownicy powinni wyłączyć wsparcie dla SSL v2 w ich przeglądarkach internetowych.
Problemy z protokołem SSL v2
Sposób negocjacji cipher suite w protokole SSL v2 umożliwia atakującemu zmuszenie serwera oraz klienta do użycia dużo słabszego szyfrowania niż są w stanie osiągnąć. Atak ten zwany jest odwróconym uzgadnianiem szyfrów (ang. cipher suite rollback). Dla przykładu, nawet jeżeli serwer oraz klient mogą użyć potrójnego DES-a (np. 168 – bitowe szyfrowanie), atakujący może zmusić obie strony do użycia 40 – bitowego szyfrowania.
Możliwe problemy protokołów TLS oraz SSL
Żadna z wersji protokołów TLS lub SSL nie chroni przeciw analizie ruchu w sieci. (ang. traffic analysis). Kryptoanalityk analizując ruch może zaobserwować liczbę wiadomości wysyłanych oraz adresy obu połączeń. Choć analityk nie wie co zawiera każda wiadomość, to jest możliwe że znajomość samej ilości przesyłanych danych pomiędzy dwoma adresami jest pożyteczną informacją. Dla przykładu, wymiana dużej ilości informacji pomiędzy dwoma oddziałami firmy znajdującymi się w różnych miastach może ułatwić przeciwnikowi analizę sposobu transmisji danego użytkownika.
Generowanie dzielonych tajnych kluczy
Rozdział ten opisuje co się dzieje po tym jak klient prześle do serwera poprzednik tajnego klucza. Serwer i klient używają poprzednika tajnego klucza, losowe wartości wymieniają w wiadomościach Hello oraz używają pseudo-losowych funkcji (PRF) do niezależnej i równoczesnej generacji głównego tajnego klucza.
Pseudo-losowe funkcje są bardzo podobne w działaniu do uruchamianych wielokrotnie funkcji tworzących skrót wiadomości. Dzięki temu tajny klucz jest na tyle przypadkowy, że uniemożliwia to atakującemu zrobieniu jego repliki. Po zakończeniu dwóch kolejek PRF, serwer i klient generują niezależnie sześć równoważnych tajnych kluczy.
W dokumentacji standardu TLS podano by pseudo-losowe funkcje używały dwóch różnych funkcji skrótów wiadomości. W przypadku gdy jedna z metod zostanie złamana, druga przypuszczalnie jest bezpieczna. Zapewnia to nas, że atakujący nie może wygenerować takich samych tajnych kluczy jak serwer i klient.
Po wygenerowaniu sześciu dzielonych tajnych kluczy, poprzednik tajnego klucza nie jest dłużej potrzebny i powinien być z powodów bezpieczeństwa skasowany.
Klient potwierdza swoja autentyczność
Jesłi serwer chce uwierzytelnić klienta, żąda on jego certyfikatu po tym jak sam go prześle. Poniżej przedstawiam poprawioną akcję komunikacji po tym jak klient prześle do serwera poprzednik tajnego klucza i swój certyfikat zawierający publiczny klucz RSA. Klient potwierdza swoją autentyczność przedstawiając, że jego prywatny klucz RSA odpowiada kluczowi publicznemu zawartemu w certyfikacie serwera. Klient tworzy skrót kombinacji tajnego klucza i kilku poprzednich wiadomości. Następnie podpisuje skrót za pomocą swojego prywatnego klucza i przesyła go do serwera. Wiadomość przesyłana do serwera nosi nazwę wiadomości weryfikującej certyfikat (ang. certyficate verify message).
Serwer weryfikuje tą wiadomość za pomocą kopii publicznego klucza klienta.
Ważne jest to, że jeżeli nawet atakujący zdoła odszyfrować wiadomość z publicznym kluczem klienta, nie może on zdobyć tajnego klucza serwera oraz klienta ponieważ klient tworzy skrót z tajnego klucza przed podpisaniem go. Musisz wiedzieć, że w przypadku takich funkcji skrótu wiadomości jak MD5 lub SHA-1 nie możliwe jest odzyskanie oryginalnej wiadomości.