infrastruktura klucza publicznego

Infrastruktura klucza publicznego (PKI) to zestaw polityk, procesów, serwerów, oprogramowania i stanowisk służących do zarządzania certyfikatami i parami kluczy, w tym do wydawania, utrzymywania i unieważniania certyfikatów klucza publicznego ^[1]. PKI odpowiada na podstawowy problem kryptografii asymetrycznej: skąd wiadomo, że dany klucz publiczny naprawdę należy do deklarowanego właściciela. Odpowiedzią jest certyfikat cyfrowy, czyli struktura danych wiążąca wartość klucza publicznego z podmiotem ^[2]. Na PKI opiera się między innymi TLS, a więc każde połączenie HTTPS ze stroną internetową.

Jak działa

Użytkownik klucza publicznego musi mieć pewność, że odpowiadający mu klucz prywatny należy do właściwego podmiotu ^[2]. PKI przenosi tę pewność z bezpośredniej znajomości na zaufanie do pośrednika. Urząd certyfikacji (CA) sprawdza tożsamość wnioskodawcy albo jego kontrolę nad domeną, a następnie podpisuje certyfikat swoim kluczem prywatnym. Przeglądarka albo system operacyjny ma listę zaufanych certyfikatów głównych i sprawdza, czy łańcuch podpisów prowadzi od certyfikatu serwera do jednego z nich. RFC 5280 opisuje ten proces jako algorytm walidacji ścieżki certyfikacji ^[2].

Przebieg wydania i weryfikacji certyfikatu dla serwisu WWW pokazuje schemat poniżej.

RYS. 1Od klucza do zaufanego połączenia

Certyfikat ma ograniczony okres ważności, ale bywa potrzebne jego wcześniejsze unieważnienie, na przykład po kradzieży klucza prywatnego. Służą do tego listy unieważnionych certyfikatów (CRL): według RFC 5280 to oznaczona czasem lista, podpisana przez CA lub wystawcę CRL i udostępniona publicznie w repozytorium ^[2].

Składniki

RFC 5280 wymienia pięć rodzajów podmiotów w modelu PKI dla internetu ^[2].

Definicje używane przez NIST podkreślają, że PKI to nie tylko technika. Jedna z nich, pochodząca z CNSSI 4009-2022, mówi o architekturze, organizacji, technikach, praktykach i procedurach, które razem wspierają działanie systemu kryptografii klucza publicznego opartego na certyfikatach ^[1]. Inna, z FIPS 186-5, streszcza PKI jako ramy do wydawania, utrzymywania i unieważniania certyfikatów ^[1].

Poza tymi rolami PKI obejmuje dokumenty: politykę certyfikacji i regulamin postępowania CA. Od nich zależy, jak dokładnie sprawdzana jest tożsamość i jak chronione są klucze urzędu, często w module HSM.

W WordPressie

WordPress korzysta z PKI w dwóch kierunkach. Jako serwer WWW strona przedstawia przeglądarce certyfikat SSL/TLS. Dokumentacja podaje, że WordPress jest w pełni zgodny z HTTPS, gdy na serwerze zainstalowano certyfikat TLS/SSL ^[6]. Stała FORCE_SSL_ADMIN w pliku wp-config.php wymusza logowanie i wszystkie sesje panelu przez SSL ^[6]. Certyfikat może być wystawiany automatycznie, na przykład przez Let's Encrypt. Ten urząd używa protokołu ACME: sprawdza kontrolę nad domeną przez rekord DNS albo plik pod ustalonym adresem na serwerze i wydaje certyfikat bez udziału człowieka ^[4].

Jako klient WordPress łączy się z innymi serwerami: pobiera aktualizacje, rozmawia z API wtyczek i usług płatniczych. Funkcje HTTP API domyślnie weryfikują certyfikat drugiej strony (argument sslverify, domyślnie włączony) i korzystają z pakietu zaufanych certyfikatów głównych dołączonego do rdzenia, wp-includes/certificates/ca-bundle.crt ^[7]. Wyłączenie sslverify we wtyczce, spotykane jako obejście błędów połączenia, odbiera tej komunikacji ochronę przed atakiem man-in-the-middle.

Zagrożenia i skutki

Siła PKI zależy od najsłabszego zaufanego urzędu. Przypadek DigiNotar pokazał, że przejęty urząd może wystawić certyfikat dla cudzej domeny, w tym przypadku dla serwisów Google ^[5].

• Fałszywy certyfikat. Pozwala podszyć się pod serwis i podsłuchać ruch w ataku man-in-the-middle.
• Kradzież klucza prywatnego. Kto ma klucz serwera, może udawać serwer do czasu unieważnienia certyfikatu. W Let's Encrypt unieważnienie zleca się żądaniem podpisanym kluczem konta uprawnionego dla domeny, a urząd publikuje informację na liście CRL ^[4]; stąd znaczenie zarządzania sekretami i rotacji kluczy.
• Nieskuteczne unieważnianie. Certyfikat unieważniony, ale wciąż akceptowany przez klienta, działa dalej.
• Wygaśnięcie certyfikatu. Przeglądarka przestaje ufać połączeniu i wyświetla ostrzeżenie zamiast strony.

Jak się bronić

Dla właściciela strony podstawą jest automatyczne odnawianie certyfikatu przez ACME ^[4] i ochrona klucza prywatnego na serwerze. Przeglądarkę warto zobowiązać do używania wyłącznie HTTPS nagłówkiem HSTS (HTTP Strict Transport Security). W kodzie wtyczek nie należy wyłączać weryfikacji certyfikatu w żądaniach HTTP ^[7].

Drugą warstwą jest przejrzystość certyfikatów (Certificate Transparency). RFC 6962 opisuje protokół publicznego rejestrowania certyfikatów TLS w chwili wydania, który pozwala każdemu audytować działania urzędów i zauważyć podejrzane certyfikaty ^[3]. Właściciel domeny może w ten sposób wykryć certyfikat wystawiony dla jego strony bez jego wiedzy. W dłuższej perspektywie PKI czeka też migracja do algorytmów odpornych na komputery kwantowe, opisana w haśle kryptografia postkwantowa.

Historia i przykłady

Najczęściej przywoływanym przykładem awarii PKI jest holenderski urząd DigiNotar. 29 sierpnia 2011 roku Mozilla poinformowała o wydaniu co najmniej jednego fałszywego certyfikatu SSL dla publicznych serwisów należących do Google ^[5]. W odpowiedzi Mozilla wydała poprawki Firefoksa, Thunderbirda i SeaMonkey, które odebrały zaufanie certyfikatowi głównemu DigiNotar ^[5]. Przypadek pokazał, że pojedynczy przejęty urząd może zagrozić użytkownikom serwisów, z którymi nie ma nic wspólnego,. Opublikowany w czerwcu 2013 roku RFC 6962 opisuje mechanizm, który pozwala zauważać takie podejrzane certyfikaty ^[3].