SSL jest do bani

Popularny standard SSL i jego rozwinięcie TLS bazują na mechanizmach, które w praktyce uniemożliwiają szybkie rozpoznawanie wadliwych certyfikatów i nie pozwalają sprawnie zarządzać zaufaniem. W efekcie prawie każda agencja wywiadowcza świata może mieć dostęp do naszych danych.

Wprowadzenie

Zanim zaczniemy analizować dlaczego standard SSL (z ang. Secure Socket Layer) nie jest tak bezpieczny, jak mogłoby się wydawać, proponujemy krótką podróż w krainę wyobraźni, do świata handlowej wymiany i pragmatycznego zaufania. Dzięki niej będziemy mogli bez problemów pojąć proste zasady rządzące światem cyfrowych pełnomocnictw, które wydają się skomplikowane głównie ze względu na nomenklaturę związaną z ich technicznymi implementacjami.

Wyobraźmy sobie zatem świat bez pieniądza i powołajmy w nim do życia głównego bohatera historii – programistę zastosowań sieciowych. Gdy czegoś mu brak, nie może po prostu wybrać się do sklepu i zapłacić gotówką lub kartą – musi dokonywać wymiany barterowej. Załóżmy, że pewnego dnia postanowił nabyć skrzynkę coli, bo poprzednia została już w całości opróżniona. Cóż robi? Nie zwlekając kopiuje na pendrive’a ostatnio napisany skrypt do inspekcji strumieni protokołu SMTP i wyrusza w miasto szukać nabywców.

Niestety, w sklepie spożywczym nie ma zapotrzebowania na tego typu narzędzie, więc udaje się do operatora telekomunikacyjnego, który doświadcza pewnych anomalii związanych z ruchem wymienianym między klientami a serwerami poczty elektronicznej. Ten, po podpisaniu stosownych umów o nieujawnianiu i umowy licencyjnej, daje mu w zamian za program pewną liczbę kart pozwalających na doładowanie rachunku telefonicznego. Nasz bohater wymienia je w pobliskim kiosku na czasopisma, które czyta personel sklepu – oczywiście część kart zostawia sobie na wypadek, gdyby skończył się proszek do prania. Z gazetami pędzi wprost do supersamu i już w kilka dni lub tygodni po napisaniu skryptu jest w stanie zaspokoić pragnienie. Tak wyglądałby świat, w którym nie korzysta się z uniwersalnych środków wymiany gospodarczej, czyli z waluty.

Funkcją pieniądza – specyficznego towaru wyrażającego wartość innych towarów – jest usprawnianie handlu. Pod jednym ważnym warunkiem: wszyscy posługujący się nim muszą zgodzić się na to, aby właśnie w danej walucie były wyrażane ceny. Poza zgodą musi też istnieć zaufanie do instytucji, która trudni się emisją waluty i wprowadzaniem jej do obrotu, w zależności od ogólnej kondycji całej lokalnej gospodarki. Dzięki temu uczestnicy rynku mają motywację do pracy i wymiany usług oraz dóbr na środek płatniczy – wiedzą, że istnieje ktoś, kto dba o to, aby z dnia na dzień ich oszczędności nie stały się bezwartościowe, na przykład z powodu wprowadzenia do obrotu takiej ilości pieniądza, która przestanie odzwierciedlać wartość dóbr i pracy.

Handel istnieje tylko dzięki zaufaniu.
– Napoleon Bonaparte

Oczywiście w przypadku potężnego kryzysu na tzw. rynku walutowym, usługodawca czy sprzedawca może próbować ratować interes żądając zastępczych środków wymiany – takich, do których ma większe zaufanie niż do emitenta: innej waluty, weksli pod zastaw, a nawet metali szlachetnych. W praktyce jednak pieniądz jest tak powszechną i zakorzenioną wartością wymienialną, że krach musiałby być naprawdę duży, aby podobny scenariusz się ziścił – bankructwo państwa, ogólnokrajowy kataklizm, jednoczesna awaria systemów przetwarzania we wszystkich większych bankach.

Obywatele nie mają więc wyjścia – muszą posługiwać się popularnym i zaaprobowanym środkiem płatniczym w codziennej wymianie handlowej. Obserwując co wyczyniają banki czy emitenci, mogą utracić osobiste zaufanie, jakim darzą walutę, jednak w pojedynkę nie są w stanie tego efektywnie wyrazić, nie są w stanie się zbuntować.

Poza walutą istnieją też inne ekonomiczne „talizmany”, które niosą informację o wartości danej rzeczy czy usługi. Przykładem mogą być certyfikaty wydawane przez firmy i stowarzyszenia, a także dyplomy różnorakich uczelni. Służą one zaświadczeniu, że legitymująca się nimi osoba została sprawdzona i można polegać na jakości dostarczanych przez nią usług czy dóbr. Tutaj sytuacja z brakiem zaufania jest zgoła inna. Klient – na przykład agencji reklamowej, której zlecił promocję swojej marki, lecz poczuł się rozczarowany jej działaniami (np. nadgorliwym czarnym PR-em czy jakością prowadzonej kampanii) – może przestać ufać podmiotowi, który certyfikował usługodawcę. Jest też w stanie przestrzec innych potencjalnych klientów i potwierdzić, że poświadczenie, któremu zaufał (czyli certyfikat) jest mało wartym świstkiem.

Gdy informacja się rozniesie, pierwotny organ certyfikujący może podjąć działania kontrolne w stosunku do własnego przedstawicielstwa, które wydało feralną opinię o rzekomej jakości usług agencji. Ono z kolei może pociągnąć do odpowiedzialności podwykonawcę zatrudnionego na potrzeby procesu kontroli jakości. Motywacją do takich działań będzie obawa przed tym, że część potencjalnych klientów utraci zaufanie do certyfikatów opatrywanych marką wydawcy i stracą one wartość. W efekcie usługodawcy, którzy do tej pory szczycili się posiadanym odznaczeniem, najprawdopodobniej zrezygnują z niego i wybiorą bardziej skrupulatnego opiniodawcę.

Tak działa wolny rynek – uczestnicy swobodnej wymiany na podstawie przyjętych kryteriów dokonują wyborów, które mają prowadzić do zdobycia klientów i maksymalizacji sprzedaży. Organowi certyfikującemu zależy więc na tym, aby unikać wpadek i naprawdę kontrolować jakość.

Mechanizmy rynkowe rządzące standardem SSL (z ang. Socket Secure Layer – bezpieczna warstwa gniazdowa) i jego rozwinięciem TLS (z ang. Transport Layer Security – bezpieczeństwo warstwy transportowej) działają na podobnych zasadach. Istnieją organy certyfikujące najwyższego poziomu, które z użyciem cyfrowych pełnomocnictw pozwalają wyznaczonym jednostkom organizacyjnym i partnerom na wydawanie tzw. certyfikatów cyfrowych, czyli kryptograficznych gwarancji, świadczących o tym, że dana strona komunikacji jest naprawdę tą, za którą się podaje. Gdzie jest więc haczyk? Okazuje się, że w przypadku wykrycia nieprawidłowości w działaniach wydawcy certyfikatu – np. potwierdzonych, pomyślnie przeprowadzonych ataków – klienci w praktyce nie mogą przestać im ufać. Właściwie mogą to zrobić, lecz skutki rezygnacji byłyby podobne do decyzji sprzedawcy lub nabywcy o tym, że przestaje się posługiwać walutą i wraca do handlu wymiennego.

SSL i TLS – jak to działa?

Standard SSL i jego rozwinięcie TLS pozwalają zabezpieczyć międzyprocesowy kanał komunikacyjny wykorzystując szyfrowanie i mechanizmy infrastruktury klucza publicznego (ang. Public Key Infrastructure, skr. PKI). Do tych ostatnich zalicza się cyfrowe weryfikowanie i potwierdzanie tożsamości komunikujących się stron, cyfrowe podpisywanie danych (w tym kluczy kryptograficznych), mechanizmy wymiany oraz certyfikacji kluczy, a także sposoby udzielania pełnomocnictw pozwalających cedować na inne podmioty odpowiedzialność za zarządzanie systemem kryptograficznym.

Podobnie jak inne mechanizmy kryptograficzne, SSL i TLS pozwalają zadbać o trzy podstawowe właściwości bezpiecznego przetwarzania danych: poufność (niezaufana strona nie może poznać treści), integralność (da się sprawdzić, czy dane nie zostały zmienione w trakcie transmisji bądź składowania) i wiarygodność (można ustalić poziom zaufania i sprawdzić podmioty odpowiedzialne za proces przetwarzania i zabezpieczania informacji). Aby poprawnie zabezpieczyć dane, wszystkie trzy wymienione składniki muszą bezbłędnie realizować powierzone im zadania ochronne.

Protokoły SSL i TLS wykorzystywane są do zabezpieczania innych protokołów. Ich implementacje, z których najpopularniejszą jest biblioteka programistyczna OpenSSL, operują na danych warstwy transportowej modelu ISO/OSI, to znaczy dostarczają interfejs programisty, który pozwala ustanowić bezpieczne połączenie z użyciem tzw. mechanizmu gniazd (ang. sockets). Te ostatnie są popularnym sposobem komunikacji międzyprocesowej i w obsłudze przypominają zwykłe pliki lub łącza komunikacyjne (ang. pipes) – można zapisywać do nich i odczytywać z nich dane, korzystając z systemowych deskryptorów i funkcji wejścia/wyjścia. Po ustanowieniu bezpiecznego połączenia aplikacja wymienia informacje w taki sam sposób, jak w przypadku połączenia nieszyfrowanego, chociaż konwencjonalnie przyjęło się, że warianty znanych protokołów aplikacyjnych, w których komunikacja jest chroniona nazywane są odmiennie. Mamy więc HTTPS (szyfrowany wariant protokołu HTTP), POP3S (wariant POP3), IMAPS (IMAP), SMTPS (SMTP) itd.

Zanim przejdziemy do omawiania problemów (w szczególności związanych z wiarygodnością), przypomnijmy sobie sposoby, które pozwalają na kryptograficzne zabezpieczenie kanału komunikacyjnego. Najefektywniejszym jest tzw. szyfrowanie symetryczne, czyli takie, gdzie ten sam sekret (np. hasło czy długi ciąg bitów) wykorzystywany jest zarówno do szyfrowania, jak i odszyfrowywania danych. Prostym przykładem szyfru symetrycznego jest Szyfr Cezara, w którym każdą literę tekstu jawnego zastępuje się inną, przesuniętą o stałą liczbę pozycji w alfabecie. Bardziej skomplikowane i znacznie bezpieczniejsze algorytmy to np. 3DES czy AES.

Problemy szyfrowania symetrycznego

Aby nadawca mógł bezpiecznie wymieniać dane z odbiorcą, muszą oni wcześniej spotkać się lub w inny sposób dokonać wymiany klucza wykorzystywanego do zabezpieczania informacji. Dlaczego? Jeżeli klucz zostałby wysłany przez niezabezpieczone medium, to potencjalny napastnik, który podsłuchuje transmisję, wszedłby w jego posiadanie i byłby w stanie poznać zawartość całej dalszej komunikacji – oczywiście pod warunkiem, że wcześniej miałby sposobność pasywnego śledzenia strumienia danych.

Wymiana klucza z użyciem innego medium byłaby szczególnie uciążliwa w przypadku serwisów internetowych. Aby na przykład odwiedzić chronioną protokołem HTTPS stronę popularnego serwisu społecznościowego czy sklepu, należałoby wcześniej udać się do ich siedziby i uzyskać wspólny klucz (wariant najbezpieczniejszy), ewentualnie otrzymać go konwencjonalną pocztą lub z użyciem wiadomości SMS. Pomijając niewygodę i koszty takiego rozwiązania, problem miałby również usługodawca, ponieważ na jego barkach spoczywałby obowiązek rozpoznawania każdego klienta, aby tworzyć na potrzeby jego sesji osobny klucz.

Bezpieczna wymiana klucza

W kłopotach związanych z wymianą klucza bezpiecznym kanałem pomagają mechanizmy wymiany klucza, na przykład protokół wymiany klucza Diffiego-Hellmana (ang. Diffie-Helman Key Exchange, skr. D-H). Można ich użyć do uzgodnienia wspólnego klucza sesyjnego przez niezabezpieczone medium bez ryzyka poznania jego zawartości w przypadku nasłuchu prowadzonego na kanale komunikacyjnym. W przypadku D-H do bezpiecznego ustalenia wspólnego sekretu wykorzystuje się trudność obliczenia logarytmów dyskretnych w ciałach skończonych.

Problem z wymianą kluczy tymi metodami polega jednak na tym, że chociaż nie można ich podsłuchać, to z powodzeniem da się przeprowadzać ataki typu Man-in-the-Middle (skr. MITM), czyli takie, w których niewidoczny pośrednik jest w stanie kontrolować przepływ informacji. Nawet gdy uda się bezpiecznie uzgodnić tymczasowy klucz, to wciąż nie jest rozwiązana kwestia tożsamości drugiej strony – szczególnie, że mamy tu do czynienia z kluczami generowanymi raz na jakiś czas dla każdego klienta z osobna. Tak więc mimo bezpiecznego sposobu uzgadniania klucza, proces zabezpieczania komunikacji wymaga dodatkowej weryfikacji, tzn. sprawdzenia czy zdalny system, który bierze udział w wymianie danych, ma prawo występować w imieniu konkretnej osoby lub instytucji.

Szyfrowanie asymetryczne

Kłopoty z koniecznością bezpiecznej wymiany klucza i jego ponownego użytku przez wielu klientów rozwiązują algorytmy szyfrowania asymetrycznego. Najpopularniejsze z nich to RSA (od nazwisk twórców: Rona Rivesta, Adiego Shamira i Leonarda Adlemana), ElGamal (od nazwiska twórcy, Tahera Elgamala) i algorytmy bazujące na wykorzystaniu krzywych eliptycznych (ang. Elliptic Curve Cryptography, skr. ECC).

Szyfrowanie asymetryczne polega na użyciu nie jednego, lecz pary kluczy, składającej się z części prywatnej i publicznej, które zwą się odpowiednio kluczem prywatnym i kluczem publicznym. Są one ze sobą matematycznie powiązane i szyfrując dane jednym z nich, można je odszyfrować wyłącznie drugim.

Klucz publiczny, jak sama nazwa wskazuje, można upubliczniać – dzięki temu każdy, kto zechce bezpiecznie bezpiecznie komunikować się z jego właścicielem, może użyć go do zaszyfrowania wiadomości lub strumienia danych. Tylko posiadacz klucza prywatnego skojarzonego z kluczem użytym do zaszyfrowania jest w stanie odwrócić proces i uzyskać jawną postać danych. Rozwiązuje to kwestię konieczności generowania wielu różnych kluczy dla wielu klientów, lecz wciąż pozostaje otwarty problem zaufania, jakim obdarza się otrzymany po raz pierwszy klucz publiczny. Jeżeli potencjalny napastnik będzie w stanie przechwycić komunikację dwóch stron za pierwszym razem, to może zaproponować im spreparowane klucze publiczne i tym samym unieważnić poufność kryptosystemu. Wiąże się to z ryzykiem podszywania się (ang. spoofing) pod drugą stronę i podsłuchiwania (ang. sniffing) komunikacji.

Aby zaradzić wspomnianemu wyżej problemowi, opracowano dodatkowe mechanizmy, pozwalające na poświadczanie autentyczności kluczy publicznych. Najpopularniejszym z nich jest użycie tzw. certyfikatów cyfrowych, czyli certyfikatów klucza publicznego.

Cyfrowa tożsamość

Certyfikat klucza publicznego jest zbiorem danych zawierającym:

• klucz publiczny;
• informacje opisujące tożsamość właściciela klucza;
• podpis cyfrowy złożony przez zaufaną trzecią stronę, czyli uprawniony organ certyfikujący, odpowiedzialny za weryfikację wspomnianej tożsamości.

W praktyce certyfikowany podmiot samodzielnie generuje parę kluczy o zadanych parametrach (np. odpowiedniej długości), a następnie część prywatną zachowuje dla siebie, zaś publiczną wysyła wraz z dodatkowymi informacjami do organu certyfikującego (ang. Certificate Authority, skr. CA) bezpiecznym kanałem. Zadaniem tej instytucji jest sprawdzenie, czy klucz publiczny spełnia standardy, czy zaproponowane dane opisujące tożsamość są poprawne (i ew. poprawienie ich czy dopisanie własnych), a następnie cyfrowe podpisanie tak stworzonego zestawu.

Wspomniany tu podpis cyfrowy to nic innego jak suma kontrolna zbioru zawierającego klucz i dodatkowe informacje, stworzona z użyciem jednej z kryptograficznych funkcji skrótu (np. z rodziny MD czy SHA), a następnie zaszyfrowana kluczem prywatnym należącym do składającego podpis. Obserwujemy tu użyteczną właściwość kryptografii klucza publicznego, polegającą na użyciu części prywatnej klucza do szyfrowania. Każdy może taką wiadomość odszyfrować (zakładając, że pobrał klucz publiczny nadawcy), lecz nie to jest tu istotne – liczy się fakt, że tylko posiadacz klucza prywatnego mógł wygenerować komunikat i można to sprawdzić. W ten sposób zapewniana jest integralność, na której bazuje mechanizm cyfrowego podpisywania danych.

Każdy, kto jest w posiadaniu publicznego klucza sygnatariusza (w tym przypadku organu certyfikującego), będzie mógł więc sprawdzić, czy to właśnie on dokonał cyfrowego podpisania certyfikatu. Dzięki temu gwarantowana jest nierozłączność i niezmienność klucza publicznego oraz informacji związanych z tożsamością, które umieszczono w certyfikacie.

Proces certyfikacji

Proces certyfikacji osoby czy instytucji polega na uwiarygodnieniu jej klucza publicznego, który będzie wykorzystywany do zabezpieczania komunikacji z innymi przez wybraną instytucję. Certyfikowany generuje parę kluczy, a następnie tworzy tzw. żądanie podpisania certyfikatu (ang. certificate signing request), które zawiera informacje o jego tożsamości, niektóre parametry użytkowania klucza i inne istotne dane, np. nazwę DNS chronionego kluczem systemu, zwaną nazwą zwyczajową (ang. common name, skr. CN) w przypadku tzw. certyfikatów SSL dla serwerów.

Tak skonstruowane żądanie jest wysyłane do instytucji certyfikującej, której zadaniem jest zbadanie, czy podane informacje są poprawne i zgodne z rzeczywistością. W przypadku certyfikatów o zwiększonym poziomie uprawomocnienia (ang. Extended Validation SSL Certificate, skr. EV SSL) weryfikacja jest skrupulatna, a poza wysłaniem żądania podpisania wymagane jest dostarczenie odpowiednich dokumentów (np. pełnomocnictw do reprezentowania firmy i wypisów z rejestrów). W tańszych wariantach proces ogranicza się do sprawdzenia, czy wnioskujący kontroluje zapisaną w żądaniu nazwę DNS usługi i może odbywać się automatycznie lub półautomatycznie, np. przez umieszczenie w katalogu głównym serwera WWW odpowiedniego pliku wygenerowanego przez wystawcę lub dodanie wskazanego znacznika meta w kodzie HTML witryny.

Kiedy uprawniona instytucja sprawdzi wnioskującego, odsyła mu certyfikat, czyli cyfrowo podpisany zbiór zawierający nadesłany klucz publiczny i dodatkowe informacje związane z tożsamością. Certyfikat można zainstalować w aplikacji usługowej, która będzie go wysyłała klientom podczas ustanawiania bezpiecznego połączenia TLS/SSL. W przypadku certyfikatów S/MIME, służących do szyfrowania i potwierdzania tożsamości nadawcy wiadomości poczty elektronicznej, otrzymany zbiór instaluje się w kliencie poczty lub przewidzianym do tego, systemowym repozytorium.

Standard X.509 i ścieżki pełnomocnictw

W przypadku protokołów SSL i TLS powszechnie stosowanym standardem zapisu wymienianych i użytkowanych informacji kryptograficznych jest X.509 – stworzony pod koniec lat siedemdziesiątych i pozostający w użyciu od roku 1988. Doczekał się on normalizacji (norma ISO/IEC 9594-8:2005 i polska norma PN-ISO/IEC 9594-8:2006), a na terenie Polski instytucją odpowiedzialną za certyfikowanie innych krajowych wystawców certyfikatów (formalnie, nie technicznie) jest Narodowe Centrum Certyfikacji.

W standardzie X.509 określono formaty przechowywania certyfikatów kluczy publicznych, kluczy, unieważnień certyfikatów (ang. certificate revocation list, skr. CRL) i certyfikatów atrybutu (ang. attribute certificate, skr. AC). Te ostatnie pozwalają określać jakie operacje mogą wykonywać ich posiadacze, to znaczy służą poinformowaniu zainteresowanych, że dana osoba lub instytucja ma uprawnienia dostępu do pewnych zasobów lub wykonywania pewnych czynności. Certyfikaty tego typu wystawiane mogą być nie tylko przez publicznie działające i zaufane urzędy certyfikujące, lecz również przez dowolne podmioty chcące udzielić dostępu do zasobów bądź operacji konkretnym podmiotom. Dzięki temu daje się z nich korzystać w różnych kontekstach bezpieczeństwa, np. do wewnętrznego zarządzania uprawnieniami w obrębie jakiejś organizacji, przy czym osobną kwestią jest ustalanie poziomu zaufania do kluczy, którymi tego typu certyfikaty podpisano.

Certyfikaty CA

Certyfikat urzędu certyfikującego (ang. Certificate Authority certificate, skr. CA certificate) to certyfikat z ustawioną flagą informującą o tym, że skojarzony z nim klucz prywatny może być wykorzystywany do składania cyfrowych podpisów na innych kluczach, czyli do generowania certyfikatów.

Certyfikaty pośrednie i główne

Certyfikat pośredni (ang. intermediate certificate) pozwala na budowanie tzw. ścieżek pełnomocnictw, dzięki którym zaufana instytucja certyfikująca (CA) jest w stanie uprawomocnić inne podmioty do działania w jej imieniu. Jest to możliwe dzięki wykorzystaniu podpisów cyfrowych składanych przez kolejne instytucje w ścieżce certyfikatów, aż do klucza organizacji certyfikującej najwyższego poziomu. Tę ostatnią nazywamy głównym urzędem certyfikującym (ang. Root Certificate Authority, skr. Root CA), a jej certyfikat klucza publicznego certyfikatem głównym (ang. root certificate). Jest on podpisany samodzielnie (ang. self-signed) przez instytucję, czyli z użyciem jej własnego klucza prywatnego. W tej chwili na świecie istnieje kilkadziesiąt organizacji, które są uznanymi przez producentów oprogramowania organami certyfikującymi najwyższego poziomu.

Główny organ certyfikujący może użyć swojego klucza prywatnego do cyfrowego podpisania certyfikatu, w którym ustawiono atrybuty świadczące o jego przeznaczeniu do podpisywania innych certyfikatów. W takim dokumencie poświadczającym (ukształtowanym zgodnie z wytycznymi standardu X.509) poza standardowymi polami obecnymi w certyfikacie klucza publicznego (określającymi: czas ważności, numer seryjny, użyte algorytmy, informacje o wystawcy i certyfikowanym podmiocie), znajdą się również flagi rozszerzeń X509v3 wskazujące na to, że mamy do czynienia z certyfikatem CA (CA:TRUE) i definiujące przeznaczenie klucza: CRL Sign (podpisywanie list unieważnień), Certificate Sign (podpisywanie kluczy). W szczególnych przypadkach pojawić się mogą również opcje zezwalające na użytkowanie certyfikatu (a właściwie skojarzonych z nim kluczy) do szyfrowania kluczy i składania generycznych podpisów cyfrowych.

Certyfikaty klienckie

Czasem istnieje potrzeba, aby to klient udowodnił swoją tożsamość względem usługi, z której zamierza skorzystać. W takich wypadkach przydaje się skorzystanie z tzw. certyfikatu klienckiego (ang. client certificate). Działa on i wygląda podobnie, jak certyfikaty dla serwerów, lecz rolę wystawcy certyfikatów pełni najczęściej dostawca usługi, w którego gestii leży weryfikacja tożsamości klienta przed złożeniem podpisu na żądaniu.

Dzięki certyfikatom klienckim (wykorzystywanym np. w bankowości elektronicznej czy do autoryzowania połączeń VPN) serwer, do którego połączenie wykonuje klient (np. przeglądarka WWW czy klient wirtualnej sieci prywatnej), może zabezpieczyć się przed atakami typu MITM (w razie, gdyby potencjalny napastnik poznał dane uwierzytelniające). Certyfikat kliencki, jeżeli jest użytkowany, jest przesyłany serwerowi w fazie negocjowania bezpiecznego połączenia, tuż po otrzymaniu i sprawdzeniu certyfikatu serwera.

Zarządzanie zaufaniem

Newralgicznym elementem zarządzania zaufaniem w przypadku SSL/TLS i X.509 jest urząd certyfikujący, który pełni rolę zaufanej trzeciej strony odpowiedzialnej za poświadczanie, że dane w certyfikacie przedstawianym przez serwer są zgodne z rzeczywistością. Zadaniem podpisującego certyfikat jest również sterowanie niektórymi parametrami umieszczanymi wraz z kluczem (np. czasem przydatności do użytku czy flagami określającymi przeznaczenie generowanego certyfikatu).

Spróbujmy na przykładzie zobrazować, jak na poziomie technicznym przejawia się zarządzanie zaufaniem do urzędów certyfikujących, czyli do wystawców certyfikatów. Wiemy już w jaki sposób tworzone są asymetryczne klucze i jak dochodzi do zmiany klucza publicznego w certyfikat stanowiący kryptograficzną wizytówkę serwisu czy osoby. Spójrzmy jednak na sprawę od strony procesu wymiany danych i zbadajmy co się dzieje podczas nawiązywania bezpiecznego połączenia.

Tuż po podłączeniu się klienta (np. przeglądarki WWW) do serwera (np. serwera WWW) z użyciem protokołu HTTPS, dochodzi do wstępnej wymiany informacji o tym, jakie są obsługiwane sposoby szyfrowania, cyfrowego podpisywania i wymiany informacji o kluczach. Poza tym serwer i klient wymieniają dwie losowe liczby, które przydadzą się później. Ważnym fragmentem tego „uścisku dłoni” jest wysłanie klientowi certyfikatu serwera, zawierającego klucz publiczny tego ostatniego. Cokolwiek klient zaszyfruje otrzymanym kluczem, odszyfrować będzie mógł wyłącznie serwer, posługując się skojarzonym z nim kluczem prywatnym.

Jednak zanim dojdzie do szyfrowania, klient sprawdza, czy może zaufać serwerowi, to znaczy czy ktoś zaufany potwierdził, że przedstawiony certyfikat jest ważny i zawiera informacje dotyczące tożsamości zgodne ze stanem faktycznym. W tym celu sprawdza podpis, czyli wylicza sumę kontrolną certyfikatu i porównuje ją z sumą kontrolną uzyskaną z odszyfrowania podpisu cyfrowego, który został złożony kluczem prywatnym instytucji certyfikującej. Jeżeli otrzymane wartości skrótów są takie same, to znaczy, że zawartość podpisana przez organ certyfikujący (certyfikat) jest tą samą zawartością, którą otrzymano od serwera.

Aby sprawdzić, czy złożony podpis jest poprawny potrzebny jest klucz publiczny zaufanej trzeciej strony. Skąd klient go uzyska? Na mocy stosownych umów popularne przeglądarki i systemy operacyjne posiadają fabrycznie zainstalowane certyfikaty wszystkich ważniejszych CA, a więc też ich klucze publiczne.

Jeżeli producent przeglądarki lub systemu operacyjnego
zaufał instytucji, która podpisała certyfikat,
to zostanie on zaakceptowany.

Gdy sprawdzenie podpisu cyfrowego na otrzymanym certyfikacie serwera powiedzie się, klient tworzy tzw. wstępny klucz główny (ang. pre-master secret), korzystając z generatora liczb pseudolosowych. Następnie wysyła go serwerowi, szyfrując dane posługując się kluczem publicznym pochodzącym z uprzednio zweryfikowanego certyfikatu. Serwer deszyfruje otrzymany komunikat własnym kluczem prywatnym i do odebranego w ten sposób klucza wstępnego dołącza losowe dane wygenerowane na samym początku przez klienta i przez siebie. Tą samą operację przeprowadza klient. Dzięki temu po obu stronach powstaje taki sam klucz główny (ang. master secret), który jest bazą dla dalszej komunikacji. Zauważmy, że sekret ten jest kluczem symetrycznym.

Dlaczego komunikacja między klientem a serwerem nie odbywa się od razu w oparciu o parę kluczy, np. RSA? Implementacje asymetrycznych algorytmów szyfrowania, z którymi mamy do czynienia obecnie, pozwalają bezpiecznie dystrybuować klucze publiczne, lecz gdy chodzi o same operacje kryptograficzne są znacznie mniej wydajne (o rzędy wielkości), niż algorytmy symetryczne (z tym samym kluczem po obu stronach). Dlatego też zarówno w komunikacji strumieniowej, jak i w szyfrowaniu dokumentów oraz korespondencji, stosuje się tzw. klucze przechodnie. Są to klucze symetrycznych algorytmów szyfrujących, którymi zabezpiecza się podlegającą ochronie treść, a na początku lub na końcu uzyskanego komunikatu z szyfrogramem umieszczany jest użyty do zaszyfrowania klucz symetryczny, lecz oczywiście nie w postaci jawnej, ale zaszyfrowanej kluczem publicznym odbiorcy. Dzięki temu zachowana zostaje względnie duża wydajność, a dodatkowo można skorzystać z mechanizmów infrastruktury klucza publicznego, czyli z operacji pozwalających zarządzać zaufaniem.

Warto mieć na uwadze, że zamieszczony wcześniej schemat nawiązywania połączenia z serwerem przedstawia scenariusz, w którym certyfikat serwera podpisano kluczem głównego urzędu certyfikującego. Dzięki temu łatwiej pojąć mechanizm weryfikacji podpisu cyfrowego. Jednak często zdarza się, że certyfikat klucza publicznego podpisany jest kluczem instytucji pośredniej, a dopiero jej certyfikat (skojarzony z kluczem podpisującym certyfikaty) jest zatwierdzony przez któryś z głównych urzędów. W takim przypadku zadaniem oprogramowania klienckiego jest sprawdzenie całej ścieżki pełnomocnictw, aż do momentu, gdy trafi na certyfikat urzędu składającego podpis, któremu ufa. Aby proces ten nie był uciążliwy, usługodawcy wykorzystują przyjętą konwencję umieszczania zestawu certyfikatów urzędów certyfikujących (ang. CA bundle) w odpowiednim miejscu, z którego w razie potrzeby klient może je pobrać. Na przykład w popularnym serwerze WWW Apache, służy do tego klauzula konfiguracyjna SSLCertificateChainFile.

Problemy

Infrastruktura klucza publicznego implementowana z udziałem mechanizmów SSL i TLS oraz standardu X.509 polega obecnie na założeniach, które uniemożliwiają skuteczne i elastyczne zarządzanie zaufaniem przez tych, którym na tym zarządzaniu powinno najbardziej zależeć – użytkowników. Co ciekawe na przeszkodzie nie stoją tu względy techniczne, lecz przyjęte konwencje i standardy.

Kto zarządzania zaufaniem?

Na podstawie zebranych wcześniej informacji możemy zauważyć, że problem zaufania w X.509 rozwiązywany jest przez sygnatury cyfrowe składane:

• na dokumentach potwierdzających tożsamość
  (certyfikatach klucza publicznego),

• na dokumentach potwierdzających zdolność do podpisywania kluczy
  (certyfikatach CA),

• na dokumentach potwierdzających pełnomocnictwa do podpisywania kluczy
  (pośrednich certyfikatach CA),

• na dokumentach poświadczających zdolność dostępu do danych
  (autoryzacyjnych certyfikatach atrybutu).

Lista urzędów certyfikujących, którym użytkownik zechce zaufać, jest kwestią umowną i teoretycznie dobrowolną. Jednak korzystający z komputera nie decyduje za każdym razem o tym, jaki certyfikat zaakceptuje, lecz polega na zautomatyzowanych mechanizmach, które pomagają mu w tym procesie. Fabrycznie, po zainstalowaniu systemu operacyjnego i przeglądarki internetowej, użytkownik w domyśle ufa wszystkim certyfikatom głównych urzędów, które dostarczyli producenci wspomnianych komponentów oprogramowania. Mamy tu więc do czynienia z tak zwanym modelem opt-out – można usunąć certyfikaty zaufanych urzędów, gdy ktoś jest świadomy, że może tego dokonać i wie, jak to zrobić.

Użytkownik komputera znajduje się w sytuacji nabywcy, który na starcie nie tylko ufa głównym urzędom certyfikującym, nie tylko ufa uprawomocnionym przez nich pośrednikom (z użyciem certyfikatów pośrednich), ale też bezgranicznie ufa producentom systemów operacyjnych i przeglądarek internetowych, którzy decyzję o tym, jakim instytucjom zaufać już za niego podjęli.

Czy jest to sytuacja groźna? Dla statystycznego internauty z pewnością wygodna, bo korzystając np. z serwisu bankowości elektronicznej czy internetowego sklepu nie musi sprawdzać, czy warto zaufać konkretnym urzędom certyfikującym, a w konsekwencji wystawionym przez nie certyfikatom. Jednak wspomniana tu kwestia z góry określonych źródeł zaufania ma duży, ujemny wpływ na bezpieczeństwo systemu kryptograficznego jako całości, jeżeli uwzględnimy opisane dalej problemy powiązane.

Wszystko albo nic

Ciekawym problemem jest kwestia braku jurysdykcji uprawnień do wystawiania certyfikatów poświadczających prawo do posługiwania się nazwami domenowymi. Właściciel serwisu internetowego, który chce wdrożyć obsługę protokołu HTTPS i wyposażyć usługę w certyfikat klucza publicznego, może zlecić operację weryfikacji tożsamości i faktu, że nazwa DNS należy do niego, jednemu z kilkuset działających na całym świecie przedstawicielstw urzędów certyfikujących. Oznacza to, że każdy z nich – nawet jeżeli jego siedziba znajduje się w kraju, do którego (np. z powodu panującej korupcji) nigdy nie wybralibyśmy się w podróż – ma takie samo prawo do decydowania o tym, czy dany podmiot jest wiarygodny, czy też nie.

Uznani badacze zajmujący się prywatnością, Christopher Soghoian i Sid Stammy, stwierdzili w publikacji zatytułowanej „Certyfikowane kłamstwa: wykrywanie i ochrona przed rządowymi atakami przechwytującymi, wymierzonymi w SSL”:

Choć zwykle się tego nie zauważa, w bazującej na SSL infrastrukturze klucza publicznego wszystkie urzędy certyfikujące obdarzone są takim samym zaufaniem.

Jest to problem tym poważniejszy, że popularne przeglądarki internetowe ufają wydanym przez setki różnych przedsiębiorstw certyfikatom dla dowolnych stron. Każda z tych firm może być nakłoniona przez właściwy dla niej urząd państwowy do wystawienia certyfikatu dla dowolnej witryny WWW, a wszystkie przeglądarki bez ostrzeżenia go przyjmą.

Wobec tego użytkownicy z całego świata postawieni zostali w sytuacji, w której ich przeglądarki niebezpośrednio powierzają ich prywatne dane zagranicznym i miejscowym organom państwowym¹.

Okazuje się więc, że każda z licznych organizacji certyfikujących bądź ich przedstawicieli, którym fabrycznie ufa popularne oprogramowanie klienckie, jest w stanie wygenerować ważny certyfikat dla dowolnej nazwy domenowej.

Nie istnieje mechanizm podziału cyfrowych pełnomocnictw pod względem stref domenowych jurysdykcji. W konsekwencji dowolny przedstawiciel centrum certyfikującego może wydać certyfikat poświadczający nieprawdę, czyniąc to z własnej woli, na zlecenie agencji rządowej, albo w wyniku błędu lub zamierzonego ataku.

W efekcie użytkownik narażony jest na ataki typu Man-in-the-Middle polegające na tym, że intruz, któremu udało się przejąć kontrolę nad kanałem używanym do komunikacji, przedstawia klientowi własny certyfikat dla danej nazwy DNS i własny klucz, a w jego imieniu łączy się do właściwego serwisu. Przeglądarka nie ostrzega użytkownika, bo certyfikat podpisano zaufanym kluczem, a cyberprzestępca pośredniczy w transmisji, mogąc podsłuchiwać strumień danych i dowolnie go modyfikować.

Koszt zmiany

Nawet gdyby użytkownik zechciał wycofać zaufanie, jakim przeglądarka WWW obdarza wybrane urzędy certyfikujące, to musi liczyć się z tym, że zależnie od konkretnego produktu, będzie zmuszony poszukiwać różnych repozytoriów z certyfikatami.

Firefox ma własną bazę, natomiast Chrome, Safari i Internet Explorer korzystają z systemowego zasobnika zawierającego klucze. Warto przy okazji zaznaczyć, że nowe systemy operacyjne Microsoftu znacznie ostrożniej podchodzą do kwestii certyfikatów. Po zainstalowaniu systemu (Windows 7) w systemowej bazie nie znajdziemy więcej niż 20 rekordów. Może to jednak wprowadzać użytkowników w błąd, ponieważ system automatycznie pobiera certyfikaty, którym zaufał producent, jeżeli podczas ustanawiania bezpiecznego połączenia wykryty zostanie ich brak w lokalnym repozytorium.

Baza certyfikatów udostępniana z użyciem usługi Windows Update liczy około 300 podpisanych cyfrowo kluczy instytucji certyfikujących. Zaletą pobierania głównych i pośrednich certyfikatów urzędów wtedy, gdy są rzeczywiście potrzebne, jest możliwość szybkiego zatrzymania „epidemii” w przypadku zdyskredytowanego centrum certyfikującego. Z kolei minusem fakt, że użytkownik może mieć fałszywe przekonanie o liczbie urzędów, którym w jego imieniu ufa system Windows i programy korzystające z obecnego tam mechanizmu Trusted Root Store (czyli np. przeglądarki IE, Safari i Chrome).

Inflacja wiarygodności

Konsekwencją przyjętego modelu zarządzania zaufaniem jest również poważny kłopot w wypadku dyskredytacji urzędu certyfikującego najwyższego poziomu. Sytuacja taka spotkała w roku 2011 firmę Comodo², gdy intruzom udało się przełamać zabezpieczenia czterech przedstawicielstw spółki, dokonując m.in. ataków typu SQL Injection. W rezultacie producenci systemów operacyjnych i przeglądarek musieli wycofać z użytku niektóre certyfikaty i zastąpić je innymi, dostarczonymi przez Comodo.

W zbliżonym okresie czasu wyszło na jaw, że należący do spółki VASCO Data Security duński urząd certyfikujący DigiNotar wystawiał fałszywe certyfikaty. Okazało się, że on również padł ofiarą ataku, lecz władze przedsiębiorstwa przemilczały ten fakt. W efekcie między innymi cyberprzestępcy z Iranu weszli w posiadanie certyfikatu skojarzonego z domeną google.com i wszystkimi domenami podrzędnymi, a następnie użyli go do prowadzenia ataków typu MITM. Gdy sprawa ujrzała światło dzienne, okazało się, że podobne certyfikaty wystawiono również dla domen należących do Yahoo!, Fundacji Mozilla, WordPressa i Projektu Tor. Zaraz po odkryciu sprawy państwo ustanowiło w VASCO Data Security komisarza, a po miesiącu od tej decyzji spółka zbankrutowała. Pikanterii sprawie dodaje fakt, że DigiNotar odpowiadał również za zarządzanie certyfikatami kwalifikowanymi, wykorzystywanymi w rządowym programie PKIoverheid.

Postawmy się więc w roli użytkownika, który stwierdza, że nie ufa już temu centrum certyfikującemu i nie chce mieć z nim nic wspólnego. Jest to sytuacja podobna do tej z przykładu opisanego na wstępie: istnieje firma wydająca certyfikaty, która nie zadbała o kontrolę jakości, więc klienci przestają darzyć zaufaniem wydawane przez nią opinie.

Czy w przypadku Comodo (a także jeszcze kilku innych wystawców, których zabezpieczenia przełamano) użytkownik może tego dokonać? W teorii tak, ale w praktyce pojawią się dwa kłopoty. Pierwszy to techniczne możliwości, tzn. zablokowanie automatycznych uaktualnień certyfikatów w systemach, które na bieżąco lub cyklicznie aktualizują listę zaufanych urzędów. Najbardziej prawdopodobnym scenariuszem byłoby całkowite wyłączenie automatycznego pobierania certyfikatów i samodzielne budowanie listy podmiotów poświadczających. Jednak nawet wtedy, gdyby udało się zmusić system i przeglądarki do trwałego porzucenia certyfikatów CA jakiejś firmy, wciąż dawałby o sobie znać znacznie dotkliwszy w skutkach, kolejny problem, związany z popularnością wystawcy certyfikatów.

Comodo ma tak wielu klientów (27.6% wszystkich certyfikatów w Internecie³), że unieważnienie wszystkich kluczy tej firmy wiązałoby się z ostrzeżeniami bezpieczeństwa pojawiającymi się podczas odwiedzania bardzo wielu witryn zabezpieczonych protokołem HTTPS. Użytkownik musiałby w jakiś sposób na własną rękę weryfikować, czy strona, którą odwiedza, posługuje się certyfikatem poświadczającym prawdę o jej tożsamości i używanej nazwie domenowej. W pojedynkę jest to niemożliwe ze względu na brak odpowiednich narzędzi i niezależnych, bezpiecznych kanałów komunikacyjnych.

W segmencie sprzedaży certyfikatów istnieje oligopol i wycofanie zaufania w stosunku do niektórych centrów certyfikujących stawia użytkownika w pozycji podobnej do wspomnianej na początku rezygnacji ze środka płatniczego – teoretycznie jest w stanie to zrobić, lecz w praktyce jego codzienne życie stałoby się bardzo niewygodne.

Pod lupą agencji

Zestawiając dwa fakty – to, że oprogramowanie ufa wielu urzędom certyfikującym (włączając w to centra certyfikujące kontrolowane przez agencje bezpieczeństwa różnych państw), a także to, że przeciętny użytkownik ma związane ręce w kwestii efektywnego zarządzania zaufaniem – możemy zauważyć, jak łatwo jest zdyskredytować PKI w obecnym kształcie (bazujące na SSL/TLS). Już kilka lat temu w Stanach Zjednoczonych zaczęły pojawiać się reklamy sprzętowych serwerów pośredniczących, których funkcją jest wygodne przełamywanie zabezpieczeń tego systemu kryptograficznego.

Produkty tego typu przeznaczone są dla państwowych agencji odpowiedzialnych za bezpieczeństwo i operatorów telekomunikacyjnych. Wyposażone są zazwyczaj w kilka portów sieciowych i potrafią dokonywać deszyfrowania, ponownego szyfrowania i inspekcji zawartości bez zauważalnego spadku prędkości transmitowanych danych (wydajność przetwarzania w zależności od modelu rzędu od kilkuset megabitów do kilkunastu gigabitów na sekundę). Administrator urządzenia musi tylko dostarczyć odpowiedni klucz i skonfigurować trasy sieciowe, a sprzęt zatroszczy się o przechwytywanie danych chronionych np. protokołem HTTPS.

Urządzenia do przeprowadzania zautomatyzowanych ataków wymierzonych w SSL/TLS mogą pracować w dwóch trybach. Pierwszy wymaga dostarczenia klucza prywatnego serwera, którego ruch jest analizowany. Analogiczną sytuacją w materialnym świecie byłoby wydanie przez właściciela budynku kopii klucza do drzwi wejściowych. W majestacie prawa klucz prywatny można uzyskać od operatora usługi za sprawą sądowego lub prokuratorskiego nakazu. Wprowadzony do pamięci urządzenia klucz, wraz z odpowiadającym mu certyfikatem klucza publicznego, pozwala na przeprowadzanie ataków typu MITM, a więc również zmianę transmitowanych danych, a także na pasywne podsłuchiwanie komunikacji (ang. sniffing).

Jeżeli uzyskanie klucza prywatnego nie jest możliwe – na przykład dlatego, że atakowany podmiot znajduje się poza jurysdykcją żądającego – pozostaje atak z użyciem fałszywie poświadczonego certyfikatu klucza publicznego (ang. compelled certicate creation attack). W tym wariancie wykorzystuje się niechlubną, omówioną wcześniej właściwość SSL/TLS, polegającą na jednakowym zaufaniu do centrów certyfikujących, niezależnie od ich lokalizacji czy nazw domenowych usług, dla których wystawiane są certyfikaty.

Porównywalną sytuacją byłoby tu zmuszenie producenta zamka do drzwi wejściowych, aby w ramach czynności konserwacyjnych wymienił go na taki, który może być otwierany również dodatkowym kluczem. Tu także uprawomocnione organy władzy są w stanie nakłonić – lecz nie operatora, ale instytucję certyfikującą – do podpisania dowolnego klucza, skojarzonego z dowolną nazwą domenową i dowolnymi danymi o tożsamości. Ułatwione zadanie mają agencje tych krajów, gdzie niektóre centra certyfikacji są de facto instytucjami państwowymi.

Po uzyskaniu fałszywego certyfikatu i skojarzonego z nim klucza prywatnego, umieszcza się je w pamięci „czarnej skrzynki”, która może działać jako pośrednik w wymianie szyfrowanego ruchu, czyli pomagać w prowadzeniu ataków typu MITM. Podłączający się klienci będą obsługiwani przez wbudowany serwer proxy (przedstawiający się oszukanym certyfikatem), natomiast on w ich imieniu będzie wykonywał połączenia do właściwej usługi.

Oczywiście, można zapytać, czy opisana sytuacja jest naprawdę z gruntu zła, bo obywatele często godzą się poświęcać prywatność, aby zyskiwać bezpieczeństwo, zaś rządy państw i ich służby funkcjonują w domyśle po to, aby chronić tych obywateli przed ludźmi o niecnych zamiarach. Poza tym, gdy ktoś nie popełnia przestępstw i nie ma nic do ukrycia, to nie powinien się niczego obawiać, prawda?

Dyskusja nad zaufaniem obywatela do rządu i nad technicznym odzwierciedlaniem tego zaufania wykracza poza ramy tej publikacji, jednak warto odnotować, że w tym przypadku:

Zaufanie do urzędów certyfikujących
oznacza zgodę na inwigilację
udzieloną tysiącom ludzi na całym świecie.

Tyczy się to zarówno tych, którzy nie wybierali obecnie rządzących we własnym kraju, ale i tych, którzy nie wybierali obecnie rządzących we wszystkich krajach, w których działają urzędy certyfikujące. Pracują tam tacy jak my, ludzie z krwi i kości, narażeni na pokusy szybkiego zysku, skłonni z obawy przed niebezpieczeństwem swoim czy bliskich, przekroczyć uprawnienia i zadziałać wbrew wspólnemu dobru. To samo tyczy się instytucji, które są w stanie formalnie kontrolować wystawców certyfikatów.

Naiwnością byłoby wierzyć, że wśród tych dziesiątek tysięcy osób z całego świata nie znajdzie się ani jedna skłonna zadziałać na niekorzyść drugiego człowieka. W tym modelu PKI wystarczy jedna taka osoba, aby zdyskredytować cały system. Ograniczone zaufanie jest więc tu rozsądnym odruchem, który pozwala zachować osobistą godność, a czasem nawet uratować biznes przed zniszczeniem.

Rozwiązania

Problemy z wiarygodnością w SSL/TLS to problem wielopłaszczyznowy i nie można go rozwiązać skupiając się wyłącznie na jednej z podstawowych kwestii, do których możemy przede wszystkim zaliczyć:

• problem techniczny z trudnością zarządzania zaufaniem przez użytkownika w obrębie jego systemu,

• problem projektowy z brakiem odpowiedzialności strefowej w obrębie IKP,

• problem systemowy z brakiem realnego pluralizmu w zakresie cedowania operacji zarządzania zaufaniem.

Lepsze zarządzanie

Rozwiązaniem problemu technicznego mogłoby być uelastycznienie zarządzania certyfikatami, polegające na możliwości łatwego ich unieważniania (tymczasowego lub stałego) przez osobę użytkującą system i oprogramowanie. To ostatnie – a w szczególności przeglądarki WWW i klienty poczty elektronicznej – powinno zawierać opcje blokowania konkretnego certyfikatu serwera lub klucza instytucji certyfikującej. Owo blokowanie polegałoby na wstrzymaniu automatycznego akceptowania certyfikatów innych niż ten, któremu już zaufano (nawet, gdy spełniałyby one kryteria uwiarygodnienia w obrębie PKI). Dopiero wyraźna zgoda użytkownika, np. po obejrzeniu danych związanych z tożsamością i ścieżki pełnomocnictw, prowadziłaby do przyjęcia certyfikatu. Dzięki temu korzystający z komputera byłby w stanie zauważyć próby podmiany poświadczonego klucza serwera na inny (możliwe, że sfałszowany).

Również na poziomie samego interfejsu użytkownika i mechanizmu zarządzania lokalnym repozytorium certyfikatów warto wprowadzić takie zmiany, które umożliwiałyby użytkownikowi dokonywanie wyborów odnośnie automatycznej akceptacji nowych certyfikatów i/lub nieznanych jeszcze urzędów certyfikujących.

Strefy wpływów

Jeżeli chodzi o brak podziału na strefy odpowiedzialności (np. pod względem nazw domenowych – w przypadku certyfikatów SSL, czy pod względem krajów zamieszkania – w przypadku certyfikatów osobistych), to na drodze do rozwiązania problemu stoją przede wszystkim utarte konwencje i zależności biznesowe.

Rynek wystawców certyfikatów jest w miarę konkurencyjny między innymi dzięki temu, że dowolny urząd najwyższego poziomu i uprawomocnieni przez niego przedstawiciele mogą oferować usługi niezależnie od fizycznej lokalizacji nabywcy czy nazwy domenowej usługi, która ma być chroniona. Z technicznego punktu widzenia wymagałoby to dodania do certyfikatów CA odpowiednich pól informujących o zasięgu działania klucza podpisującego inne klucze. Rodzi to jednak pytanie o kwestię formalną, tzn. O to kto rozdzielałby uprawnienia dla stref. Najprawdopodobniej do czynienia mielibyśmy z jakimś konsorcjum lub agencją, podobnie jak działa to w przypadku protokołu DNSSEC.

Zauważmy, że już teraz istnieją instytucje wydające tzw. certyfikaty kwalifikowane, czyli możliwe do użycia przy cyfrowym podpisywaniu urzędowych dokumentów i korespondencji. Są to krajowe centra, których cyfrowe poświadczenia i pełnomocnictwa mają umocowanie prawne. W przypadku Polski są to: Krajowa Izba Rozliczeniowa, Polska Wytwórnia Papierów Wartościowych (Sigillum) i Unizeto Technologies (Certum).

Alternatywne urzędy

Najciekawszą kwestią jest pluralizm w zakresie cedowania operacji zarządzania zaufaniem. W tej chwili najmniej elastycznymi ogniwami są producenci oprogramowania (dostarczający fabryczne listy zaufanych certyfikatów) i organy certyfikujące działające w obrębie tego samego, globalnego łańcucha zaufania, w którym jedno słabe ogniwo może ujemnie wpłynąć na bezpieczeństwo pozostałych. W gruncie rzeczy chodzi tu o umożliwienie użytkownikowi wyboru odnośnie tego, komu ufa na tyle, aby wyręczał go w badaniu wiarygodności podmiotów legitymujących się certyfikatami klucza publicznego i/lub w badaniu tożsamości i wiarygodności podmiotów certyfikujących.

W tym przypadku problem mógłby być rozwiązany przez dopuszczenie w X.509 możliwości składania wielu podpisów na jednym certyfikacie. Tym sposobem społeczność sieci Internet mogłaby wyłonić z siebie alternatywne organy certyfikujące, co doprowadziłoby do zaistnienia konkurencji w zakresie wiarygodności. Użytkownik byłby w mocy decydować, że ufa wyłącznie tym kluczom, które opatrzono cyfrowymi sygnaturami nie tylko oficjalnych CA, ale też wybranych, dodatkowych urzędów, niezwiązanych bezpośrednio z podatnymi na korupcję i dyskredytację organami najwyższego poziomu znanymi teraz.

Alternatywni wystawcy certyfikatów mogliby funkcjonować w oparciu o zupełnie inne zasady, na przykład korzystać z uśrednionej reputacji, na którą składałaby się np. ocena społeczności, wiarygodność operatora, wiarygodność usługodawcy i inne parametry.

Z podobnym modelem mamy do czynienia w mechanizmie Pretty Good Privacy (skr. PGP), gdzie nie istnieją fabrycznie instalowane centra certyfikujące, lecz użytkownicy kryptosystemu wzajemnie składają podpisy na kluczach osób, których tożsamość osobiście potwierdzili. Samo oprogramowanie (np. GnuPG) pozwala następnie przypisać pewnym kluczom poziom zaufania, aby cedować zarządzanie wiarygodnością na najbardziej zaufanych znajomych (cokolwiek zostanie podpisane kluczem przyjaciela, któremu użytkownik bezgranicznie ufa, będzie uznane za godne zaufania tak samo, jakby to on o tym zdecydował).

W przestrzeni SSL/TLS również czynione były i są pewne wysiłki zmierzające do stworzenia alternatywnego łańcucha poświadczeń. Firma CAcert jest centrum certyfikującym, które wystawia certyfikaty bazując na zaufaniu, jakim obdarzyła żądającego społeczność. Można przyłączyć się do projektu i zostać społecznym notariuszem, którego zadaniem jest sprawdzanie, czy osoba bądź instytucja składająca żądanie podpisania certyfikatu jest naprawdę tym, za kogo się podaje. Problemem tego podejścia jest to, że w obecnym systemie jego wybór wiąże się z rezygnacją z certyfikatu jednego z urzędów, którym ufa popularne oprogramowanie (problem jednego podpisu). Poza tym w wielu systemach wymagana jest ręczna instalacja certyfikatu najwyższego poziomu, aby całe drzewo poświadczeń było akceptowane przez oprogramowanie.

Implementacja mechanizmu wielokrotnego podpisywania pojedynczego klucza w X.509 nie powinna być trudna – już teraz format PKCS #7 pozwala na składanie wielu podpisów. Niestety TLS go nie obsługuje. Rozwiązaniem byłaby więc albo zmiana X.509, albo włączenie obsługi PKCS #7 w TLS.

Warto nadmienić, że w przypadku szyfrowania i cyfrowego podpisywania korespondencji elektronicznej, użytkownicy już teraz mogą skorzystać z opisywanego podejścia. Wystarczy, że będą równolegle korzystali z kodowania S/MIME (bazującego na certyfikatach podpisywanych przez CA) i z PGP (bazującego na społecznościowych potwierdzeniach tożsamości). Warunkiem jest jednak obsługa przez oprogramowanie odbiorcy obu wariantów PKI.

Przeciwdziałanie

Użytkownicy, którzy chcą bezpiecznie się komunikować i nie być narażeni na ataki MITM polegające na wymuszeniu wydania fałszywego poświadczenia klucza publicznego, mogą skorzystać z różnych obejść zmniejszających ryzyko.

Własne CA

Tam, gdzie mamy do czynienia z wieloma komputerami klienckimi należącymi do jednej organizacji i nie występuje konieczność potwierdzania tożsamości usług przez użytkowników zewnętrznych, warto samodzielnie stworzyć urząd certyfikujący i zainstalować jego certyfikat na wszystkich stacjach. Dzięki temu zabiegowi nie tylko zmniejszymy koszty, ale również ryzyko ataku.

Należy jednak pamiętać o właściwym zabezpieczeniu klucza prywatnego CA, czyli przechowywaniu go na wymiennym nośniku i zabezpieczeniu hasłem, albo na umieszczeniu go na specjalnej karcie kryptograficznej.

HTTPS Everywhere

HTTPS Everywhere to opracowana i utrzymywana przez Electronic Frontier Foundation wtyczka dla przeglądarek Chrome i Firefox, której zadaniem jest upewnić się, że tam gdzie to możliwe będzie użyte bezpieczne połączenie (HTTPS). Nie zwiększa elastyczności zarządzania PKI, ani nie dodaje ochrony przed MITM, lecz jest dobrym wstępem, jeżeli chodzi o bezpieczne surfowanie w Sieci.

Cert Viewer Plus

Dodatek Cert Viewer Plus to przeznaczony dla Firefoksa plug-in, dzięki któremu można w wygodny sposób przeglądać zawartość certyfikatów. Tu również nie znajdziemy funkcji ochronnych, ale możemy dokonywać eksportu certyfikatów do różnych formatów.

Certificate Patrol

Certificate Patrol to plug-in dla Firefoksa, który pozwala nadzorować operacje przyjmowania i zmian w certyfikatach wykorzystując strategię zaufania przy pierwszym użyciu (ang. Trust-On-First-Use, skr. TOFU). Jest to obejście problemu z brakiem kontroli nad operacjami zarządzania zaufaniem przez przeglądarkę, lecz może powodować wiele fałszywych alarmów (np. gdy certyfikat zmienił się, ponieważ poprzedni został unieważniony lub właściciel usługi zdecydował się skorzystać z certyfikacji w innym urzędzie).

Perspectives

Projekt Perspectives jest próbą uporania się z systemowymi i projektowymi problemami w protokołach SSL i TLS. W jego ramach utrzymywana jest sieć publicznie dostępnych komputerów zwanych sieciowymi notariuszami. Są one odpowiedzialne za weryfikacje certyfikatów klucza publicznego, które otrzymuje oprogramowanie po podłączeniu się do serwera usługowego.

Poza sprawdzaniem, czy ścieżka pełnomocnictw jest poprawna, aplikacja korzystająca z Perspectives używa wspomnianych usług do przeprowadzenia dodatkowej weryfikacji certyfikatu. Serwery notarialne są zarządzane przez społeczność (każdy może utworzyć własny), a użytkownik oprogramowania wybiera, którym z nich zaufa w kwestii badania wiarygodności usługodawców.

Jednym z podstawowych kryteriów oceny, czy certyfikat nie został sfałszowany, jest badanie czasu jego użytkowania przez internautów. Dla niektórych udzielanie tego typu informacji może być jednak kłopotliwe ze względu na ochronę prywatności, a wysyłanie informacji związanych z przyjmowanymi certyfikatami „notariuszom” jest wymagane do poprawnej pracy.

Gotowe do użytku dodatki, które obsługują Perspectives, można pobrać w wariantach przeznaczonych dla przeglądarek Firefox i Chrome.

SSL Observatory

SSL Observatory to kolejny projekt Electronic Frontier Foundation. Jego celem jest badanie wszystkich dostępnych w Internecie certyfikatów klucza publicznego i stron WWW, które się nimi posługują. W ramach przedsięwzięcia, do którego każdy może się przyłączyć, tworzona jest publicznie dostępna baza danych kluczy, ich powiązań oraz ścieżek pełnomocnictw, wraz z oceną wiarygodności i podatności na zagrożenia.

Z projektu SSL Observatory mogą korzystać administratorzy usług sieciowych, specjaliści zajmujący się kryptografią klucza publicznego, a także twórcy rozszerzeń eliminujących problemy z wiarygodnością SSL/TLS i X.509.

Convergence

Convergence to projekt Moxiego Marlinspike’a – twórcy polityki zarządzania certyfikatami w serwisie Twitter i narzędzi takich jak sslstrip. Z założenia ma zastępować system bazujący na urzędach certyfikujących rozwiązaniem, które podobnie jak Perspectives, korzysta z sieci cyfrowych notariuszy. Użytkownik jest w stanie wybrać, którym z nich zaufa, z możliwością działania w trybie pełnej zgody, tzn. uzależniania zaufania drugiej stronie pod warunkiem, że wszyscy notariusze pozytywnie ją zaopiniują.

Istotną cechą systemu Convergence jest anonimowość, która realizowana jest przez lokalne przechowywanie informacji dotyczących zaufania i tryb maskowania oryginalnego adresu IP odpytującego przez specjalne serwery pośredniczące. Poza tym mechanizm wartościowania kluczy i usług można rozszerzać o dodatkowe moduły, np. służące do badania DNSSEC, danych BGP, czy też informacji zgromadzonych w ramach projektu SSL observatory.

TACK

TACK to skrót od Trust Assertions for Certificate Keys, co można przetłumaczyć jako poręczenia zaufania dla kluczy certyfikatów. Opracowanie, które ma już status propozycji standardu, opisuje sposób rozszerzenia mechanizmu TLS o właściwości pozwalające rozwiązać wspomniany wcześniej systemowy problem z pluralizacją odpowiedzialności za zarządzaniem zaufaniem.

TACK umożliwia klientom powiązanie specjalnych kluczy podpisujących TACK-a (ang. TACK signing key, skr. TSK) z certyfikatami klucza publicznego. Te podpisujące klucze wybierane są przez serwery i służą do cyfrowego sygnowania kluczy TLS usług, używanych do zabezpieczania transmisji. Ponieważ skojarzenia bazują na kluczach podpisujących, a nie na kluczach centrów certyfikujących (CA), więc do określenia poziomu wiarygodności nie jest wymagane zaufanie do wystawców certyfikatów. Poza tym klucze TSK mogą być użyte do unieważniania zdyskredytowanych, prywatnych kluczy TLS.

Podczas inicjowania bezpiecznego połączenia odpowiednio przystosowany serwer powiadamia klienta o obsłudze rozszerzenia TACK. W komunikacie zawarty jest też klucz publiczny TSK i cyfrowy podpis. Jeżeli klient już parokrotnie łączył się z daną usługą (o takiej samej nazwie domenowej i takim samym TSK), to wytwarza powiązanie między tą nazwą a TSK. Będzie ono ważne przez taki sam okres czasu, jaki zajęło obserwowanie pary nazwa stacji – TSK. Powiązania mogą być wymieniane między klientami, co pozwala na budowanie własnych usług zarządzających zaufaniem.

Gdyby porównać pod względem rozwiązywanych problemów rozszerzenie TACK i wspomniany wcześniej projekt Convergence, to można zauważyć, że Convergence uelastycznia zarządzanie zaufaniem, natomiast TACK znacznie ogranicza liczbę transakcji z zewnętrznymi źródłami.

Perfect forward secrecy

Utajnianie z wyprzedzeniem (ang. forward secrecy, skr. FS), zwane też doskonałym utajnianiem z wyprzedzeniem (ang. perfect forward secrecy, skr. PFS) to cecha mechanizmu wymiany klucza, która polega na tym, że klucz sesyjny wyliczany jest na podstawie pary stałych kluczy (publicznego i prywatnego), przy czym niemożliwe jest odgadnięcie klucza sesyjnego nawet, gdyby klucz prywatny został wcześniej ujawniony.

Powyższe oznacza to, że podczas nawiązywania bezpiecznego połączenia między klientem a serwerem nie dochodzi do bezpośredniego szyfrowania klucza sesyjnego z użyciem klucza asymetrycznego. W rezultacie przejęcie klucza prywatnego nie daje napastnikowi, który podsłuchiwał transmisje między usługą a klientami, żadnej przewagi – musi on przełamać każdy sesyjny klucz z osobna.

Włączając PFS w usłudze sieciowej (np. serwerze WWW), administrator może zapobiec atakom polegającym na pasywnym podsłuchiwaniu komunikacji i atakom polegającym na nakłonieniu usługodawcy do wydania klucza prywatnego. Na chwilę obecną sprawdzonym i bezpiecznym algorytmem tego typu jest Elliptic Curve Diffie-Hellman Ephemeral (skr. ECDHE).

Operatorzy publicznych usług sieciowych powinni włączyć mechanizm PFS, aby zminimalizować ryzyko elektronicznego podsłuchania przez system PRISM i podobne.