Paweł Goleń, blog

Aby zrozumieć o co chodzi, należy przyswoić sobie kilka pojęć, czyli:

• kryptografia asymetryczna
• PKI

Kryptografia asymetryczna

Kryptografia służy (ogólnie mówiąc) do ochrony informacji, w szczególności do jej utajnienia lub/i stwierdzenia, że nie została ona zmodyfikowana. Kryptografia asymetryczna charakteryzuje się tym, że używa się w niej dwóch kluczy, oddzielny klucz do szyfrowania, oddzielny do odszyfrowywania. Klucze te są ze sobą matematycznie powiązane, ale w taki sposób, że na podstawie klucza publicznego nie można obliczyć/odgadnąć odpowiadającego mu klucza prywatnego, lub co najmniej nie można zrobić tego w sensownym czasie. Co oznacza sensowny czas? Najprościej przyjąć, że atakujący odszyfrowuje coś w sensownym czasie, jeśli jest w stanie wykorzystać zdobytą w ten sposób informację. Warto zwrócić uwagę na fakt, że ile ten sensowny czas wynosi nie zależy jedynie od użytego algorytmu, ale również od chronionej informacji. Powiązania między kluczami są różne, dla lepszego zrozumienia tematu można poczytać sobie choćby o algorytmie RSA.

Klucze wykorzystywane w kryptografii asymetrycznej są określane jako klucz prywatny i klucz publiczny. Klucz prywatny, jak sama nazwa wskazuje, jest prywatny, tajny, nie wolno go ujawniać. Klucz publiczny natomiast można udostępniać osobom trzecim.

Powstaje pytanie, jak sprawdzić, czy ktoś posiada klucz prywatny odpowiadający kluczowi publicznemu. Klucz prywatny jest tajny, więc sam jako taki nie może zostać "pokazany". Co więcej, w niektórych przypadkach posiadacz klucza prywatnego nie wie, jak on "wygląda", ponieważ jest on przechowywany w urządzeniu, które pozwala co najwyżej wykonać z jego użyciem określone operacje, jednak nigdy nie uwalnia klucza. Przykładem takiego urządzenia może być choćby karta kryptograficzna. Zamiast "pokazania" swojego klucza, należy wykonać coś, co jest określane jako proof-of-possession, czyli dowód posiadania. W tym przypadku może to być po prostu wykonanie pewnej operacji, która wymaga posiadania klucza prywatnego. Taką operacją może być odszyfrowanie pewnej informacji zaszyfrowanej (poprawka: pisząc zjadłem wyraz, dzięki Przemku) przy pomocy klucza publicznego. Tylko posiadacz właściwego klucza prywatnego jest w stanie taką wiadomość rozszyfrować. Tak więc przykładowe operacje, jakie należy wykonać, mogą wyglądać tak:

• wygenerować losową liczbę,
• zaszyfrować ją przy pomocy klucza publicznego osoby, którą chcemy zweryfikować,
• przekazać zaszyfrowaną wiadomość weryfikowanej osobie,
• osoba weryfikowana ma odszyfrować wiadomość i przekazać osobie weryfikującej,
• osoba weryfikująca porównuje wygenerowaną przez siebie liczbę z liczbą uzyskaną od osoby weryfikowanej, jeśli jest to ta sama liczba, osoba weryfikowana rzeczywiście posiada klucz prywatny odpowiadający użytemu w tym algorytmie kluczowi publicznemu,

Jeśli obie strony posiadają swoje pary kluczy (każda ze stron posiada swój klucz prywatny i gdzieś są dostępne ich klucze publiczne), strony mogą zweryfikować się wzajemnie.

Do tej pory nie padło ani raz magiczne słowo certyfikat. Nie padło ono dlatego, że przy kryptografii asymetrycznej certyfikaty nie są potrzebne. Certyfikat związany jest z PKI.

PKI czyli Public Key Infrastructure jest kryptosystemem zbudowanym w oparciu między innymi o kryptografię asymetryczną. Aby zrozumieć jego przeznaczenie warto zastanowić się nad następującymi zagadnieniami:

• jak sprawdzić kto jest posiadaczem klucza prywatnego odpowiadającego określonemu kluczowi publicznemu,
• jak sprawdzić, czy posiadacz klucza prywatnego wciąż go kontroluje,

Certyfikat jest określany również często jako certyfikat klucza publicznego. Certyfikaty wystawiane są przez Urzędy Certyfikacji (CA), czyli instytucje, które można określić jako zaufane. Dobrą analogią może być tutaj kwestia wystawiania dowodów tożsamości. Osoba, która mnie nie zna, może stwierdzić, że ja to ja (w sensie mojego imienia, nazwiska oraz innych danych) poprzez weryfikację mojego dokumentu tożsamości wystawionego przez państwo, w którym żyję. W tym wypadku źródłem zaufania jest fakt zaufania do instytucji państwowych, w przypadku PKI źródłem zaufania do certyfikatów jest zaufanie do Urzędów Certyfikacji wystawiających certyfikaty, do stosowanych w nich procedur organizacyjnych oraz środków technicznych. Korzystając z OpenSSL każdy jest w stanie stworzyć swój własny, darmowy Urząd Certyfikacji, wystawione za jego pomocą certyfikaty mogą bez problemu być wykorzystane do szyfrowania poczty czy uruchomienia serwera HTTPS. W praktyce jednak żaden poważny bank czy sklep internetowy nie korzysta z wystawionych przez siebie certyfikatów. Nie dzieje się tak, ponieważ certyfikaty takie są niezbyt zaufane, nie dlatego, że pod względem technicznym są w jakikolwiek sposób gorsze od tych wystawianych przez zaufane Urzędy Certyfikacji, ale dlatego, że procedury stosowane przez zaufane Urzędy Certyfikacji są po prostu lepsze i dają większą gwarancję, że tożsamość podmiotu nabywającego określony certyfikat jest właściwie zweryfikowana.

Co zawiera certyfikat?

Certyfikat zawiera między innymi następujące informacje:

• klucz publiczny właściciela certyfikatu,
• informacje o właścicielu certyfikatu (imię, nazwisko, adres e-mail, adres/nazwę serwera),
• informacje o wystawcy certyfikatu,
• podpis wystawcy certyfikatu,
• informacje o okresie ważności certyfikatu,

Prócz tych informacji, może zawierać wiele innych. Między innymi informację o polityce, według której został wystawiony, a także adres listy CRL, gdzie publikowane są informacje o unieważnionych certyfikatach.

W końcu trochę o SSL

Chyba SSL najczęściej jest kojarzony z protokołem HTTP, a właściwie bezpieczną jego wersją, czyli HTTPS. Są to protokoły warstwy aplikacyjnej. HTTPS właściwie w niczym nie różni się od HTTP. Różnica jest niżej, można ją ulokować między protokołem warstwy aplikacyjnej, a warstwą transportową, w tym przypadku TCP (choć istnieje SSL na UPD).

Jak przebiega zestawienie połączenia SSL Przede wszystkim następuje zestawienie połączenia TCP. W oparciu o zestawione połączenie TCP następuje negocjacja protokołu SSL. Po jej zakończeniu przez zestawiony kanał SSL aplikacja może wysyłać dowolne dane. Aby pokazać jakie to jest proste, banalny przykład w Pythonie programu, który nawiązuje połączenie z serwerem SSL:

import socket
s = socket.socket() s.connect((HOST,PORT)) ssl = socket.ssl(s)

W tej chwili pod nazwą ssl mamy obiekt, który udostępnia (między innymi) metody write i read, za których pomocą można przesyłać lub odzytywać dane za pośrednictwem bezpiecznego kanału SSL.

Oczywiście to, co dzieje się po wywołaniu socket.ssl(s) jest dość złożone. Negocjowane jest połączenie SSL, weryfikowane (no, może nie akurat w tym przykładzie, ale w założeniach tak) certyfikaty, wykonywany proof-of-possession, uzgadniane klucze sesji...

Kto właściwie ma klucze...?

Klucze (a właściwie w tym przypadku certyfikat i klucz prywatny) powinien mieć serwer. W przypadku HTTPS można uznać, że serwer musi posiadać certyfikat. Certyfikat ten służy do uwierzytelnienia serwera przed klientem. Nie służy do szyfrowania. Warto powiedzieć, że do zabezpieczenia połączenia SSL wykorzystywane są szyfry symetryczne, a klucz wykorzystywany w komunikacji jest uzgadniany przez strony, na przykład za pomocą algorytmu Diffie-Hellman, do którego klucze nie są potrzebne. Możliwe jest jednak, by certyfikaty posiadały obie strony. Wówczas przed rozpoczęciem wymiany informacji obie strony mają możliwość dokonać weryfikacji tożsamości drugiej strony. W ogólności wystarczy jednak, by certyfikat posiadał serwer.

SSL1, SSL2, SSL3, TLSv1

To są wersje SSL (no, dobrze, TLS może nie jest "wersją" SSL, ale przyjmijmy takie uproszczenie). SSL1 nie występuje już praktycznie nigdzie. SSL2 wciąż można napotkać, ale jest on uznawany za protokół słaby, w którym istnieją znane podatności, dlatego też w chwili obecnej wykorzystywane są głównie SSL3 oraz TLSv1. Zarówno klient, jak i serwer mogą wspierać kilka wersji protokołu, wybierana jest najmocniejsza ze wspólnie obsługiwanych wersji.

56bit, 128bit,...1024bity?

Tutaj może być pewne nieporozumienie. Przy SSL mamy do czynienia zarówno z kryptografią asymetryczną (certyfikaty, klucze), jak i kryptografią symetryczną. Na początku wykorzystywana jest kryptografia asymetryczna. Tutaj ilość bitów oznacza długość klucza zawartego w certyfikacie. Generalnie im więcej, tym lepiej. Jeszcze kilka lat temu powszechnie używane były klucze 512 bitowe, obecnie jest to co najmniej 1024 bity, a zdarzają się certyfikaty o kluczu 2048 bitów. 512 to nieco za mało jak na obecne warunki, 1024 jest w tej chwili wystarczające. Do zabezpieczenia danych w połączeniu wykorzystywana jest kryptografia symetryczna. Tutaj klucze są krótsze. Klucze o długości 40 lub 56 bitów były wykorzystywane w czasach, gdy obowiązywały restrykcje eksportowe na technologie kryptograficzne (choć wcale nie jestem pewny, czy one nadal nie występują). Są one słabe, nie zapewniają odpowiedniego poziomu bezpieczeństwa i ich stosowanie mija się w praktyce z celem. Listę tych szyfrów można zobaczyć wydając polecenie openssl ciphers -v EXPORT, oczywiście pod warunkiem, że posiada się zainstalowanego OpenSSL. Kolejną grupą są szyfry 56 i 60 bitowe, które też na chwilę obecną nie są wystarczające. Ich listę obejrzeć można po wydaniu polecenia openssl ciphers -v LOW. Przykładowy rezultat jej wywołania:

ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 
DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 
RC4-64-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(64) Mac=MD5 
DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
    

Pierwsza kolumna oznacza nazwę szyfru (jego identyfikator), druga wersję SSL, w jakiej jest stosowany, trzecia określa metodę wymiany/uzgodnienia klucza, czwarta metodę uwierzytelnienia, piąta to wykorzystywany algorytm szyfrowania wraz z długością wykorzystywanego klucza, ostatnia kolumna pokazuje jaka funkcja skrótu jest wykorzystywana dla MAC. Kolejne grupy to MEDIUM i HIGH, które wykorzystują klucze 128 bitowe i dłuższe. Listę szyfrów można zobaczyć uruchamiając polecenia openssl ciphers -v MEDIUM oraz openssl ciphers -v HIGH. Szyfry z tych grup są już wystarczające do zapewnienia odpowiedniego poziomu bezpieczeństwa transmitowanym danym.

Podobnie jak w przypadku wersji protokołu, tak i w przypadku szyfru wybierany jest najmocniejszy ze wspólnie obsługiwanych przez klienta i serwer.

Skoro wybierany jest najmocniejszy...

...to dlaczego problemem jest obsługa "słabych szyfrów" lub SSL2, przecież i tak zostanie wybrany najsilniejszy? Problem polega na tym, że właśnie nie zawsze jest wybierany najsilniejszy. Szczególnie w przypadku SSL2 istnieją skuteczne techniki ataku pozwalające na wymuszenie wyboru słabszych szyfrów, co późnej może pozwolić atakującemu podsłuchać transmisję i rozszyfrować przesyłane dane. Dlatego dobrą praktyką jest wyłączanie SSL2, a i zablokowanie możliwości korzystania ze słabych szyfrów nie jest złym pomysłem.

Koniec i bomba a kto czytał to...

...wyniósł z tego jakiś pożytek?