PKI i Certyfikaty

Weryfikacja tożsamości cyfrowej

Weryfikacja tożsamości w świecie fizycznym opiera się na dokumencie wydanym przez określony urząd oraz na procedurze sprawdzenia jego cech i danych. Bank może ocenić dokument, porównać zdjęcie z osobą i sprawdzić, czy dokument pochodzi z akceptowanego źródła. Zaufanie wynika z zasad wydawania dokumentów, zabezpieczeń oraz odpowiedzialności podmiotu, który je wydał.

W połączeniu internetowym przeglądarka musi sprawdzić, czy klucz publiczny należy do serwera wskazanego przez użytkownika. Sama treść strony nie potwierdza tożsamości, ponieważ napastnik może przygotować jej kopię i próbować przechwycić połączenie. Certyfikaty cyfrowe, podpisy cyfrowe oraz procedury weryfikacji tworzą mechanizm, który pozwala powiązać nazwę podmiotu z kluczem publicznym. Ten mechanizm jest realizowany przez Infrastrukturę Klucza Publicznego.

Czym jest Infrastruktura Klucza Publicznego (PKI)?

Infrastruktura Klucza Publicznego (PKI) obejmuje role, polityki, sprzęt, oprogramowanie i procedury służące do tworzenia, zarządzania, dystrybucji, używania, przechowywania oraz unieważniania certyfikatów cyfrowych. Jej głównym celem jest powiązanie klucza publicznego z określonym podmiotem, takim jak osoba, organizacja albo serwer, zgodnie z ustaloną polityką zaufania.

PKI obejmuje cały cykl życia certyfikatu: zasady identyfikacji wnioskodawcy, wydanie dokumentu, ochronę kluczy, publikację certyfikatów, sprawdzanie ścieżki zaufania oraz obsługę unieważnienia. Certyfikat cyfrowy jest dokumentem zawierającym między innymi klucz publiczny i dane podmiotu. Poprawna weryfikacja wymaga zgodności dokumentu z polityką oraz sprawdzenia aktualnego statusu certyfikatu. Wdrożenie określa również sposób generowania i przechowywania kluczy prywatnych, procedury odnowienia oraz role osób uprawnionych do wydawania i unieważniania. Zaufany odbiorca musi znać politykę CA i listę akceptowanych kotwic, a właściciel certyfikatu odpowiada za ochronę klucza prywatnego. W praktyce polityka opisuje także wymagane algorytmy, długość kluczy, okresy ważności, procedury awaryjne i sposób audytu. Certyfikat nie zastępuje kontroli dostępu. Potwierdza określone powiązanie klucza z podmiotem, a aplikacja nadal decyduje, jakie uprawnienia przyznać. Polityka określa również odnowienie, odzyskiwanie po przejęciu klucza, przechowywanie dowodów i odpowiedzialność stron ufających. Te zasady decydują o przydatności certyfikatu w całym cyklu jego życia.

Podstawowe komponenty PKI

PKI składa się z ról i komponentów, które współpracują przy wydawaniu certyfikatów, weryfikacji tożsamości, publikacji danych oraz utrzymaniu zaufania.

1. Urząd Certyfikacji (CA): wydawanie certyfikatów.

   Urząd Certyfikacji (CA) wydaje certyfikaty zgodnie ze swoją polityką i chroni klucz prywatny używany do podpisywania. Przed wydaniem certyfikatu CA stosuje określone metody weryfikacji wnioskodawcy. Podpis CA pozwala odbiorcy sprawdzić, że przedstawiony certyfikat został wydany przez wskazanego wystawcę i nie zmieniono jego podpisanych danych. Zaufanie do CA wynika z umieszczenia jego klucza w konfiguracji odbiorcy jako kotwicy lub zbudowania ścieżki do takiej kotwicy. CA może wydawać certyfikaty końcowe albo pośrednie certyfikaty CA. Przykładowe publiczne CA to DigiCert, GlobalSign oraz w Polsce Certum (Asseco).

2. Urząd Rejestracji (RA): obsługa wniosków.

   W dużych wdrożeniach PKI CA może delegować weryfikację tożsamości oddzielnemu podmiotowi, czyli Urzędowi Rejestracji (RA). RA przyjmuje wnioski, wykonuje wstępne sprawdzenia zgodnie z polityką CA i przekazuje zweryfikowany wniosek do CA. RA nie musi podpisywać certyfikatu. Końcowe wydanie pozostaje czynnością CA. Rozdzielenie RA i CA ogranicza liczbę osób mających dostęp do klucza podpisującego. Procedury powinny określać przekazywanie wniosku, przechowywanie dowodów weryfikacji oraz obsługę odrzuconych i wygasających certyfikatów.

3. Certyfikaty cyfrowe: dokumenty X.509.

   Certyfikat cyfrowy jest elektronicznym dokumentem używanym w PKI. Najczęściej ma strukturę X.509 i zawiera informacje wiążące tożsamość podmiotu z jego kluczem publicznym. Zdefiniowane pola oraz podpis wystawcy umożliwiają walidację dokumentu.

4. Mechanizmy unieważniania certyfikatów (CRL i OCSP).

   Jeśli klucz prywatny zostanie ujawniony albo zmienią się warunki zaufania, CA może unieważnić certyfikat przed jego wygaśnięciem. PKI publikuje informacje o statusie certyfikatów przez Listę Unieważnionych Certyfikatów (CRL) oraz Protokół Statusu Certyfikatu Online (OCSP). Oprogramowanie sprawdza te informacje zgodnie z własną polityką walidacji.

5. Repozytorium certyfikatów: publikacja danych.

   Repozytorium jest katalogiem lub bazą danych, w której CA publikuje wydane certyfikaty, listy CRL i informacje potrzebne do walidacji. Użytkownik lub aplikacja może pobrać certyfikat oraz dane statusu zgodnie z polityką dostępu. Punkty publikacji i adresy usług statusowych są wskazywane w certyfikacie albo w konfiguracji klienta.

Struktura certyfikatu cyfrowego X.509

Certyfikat X.509 ma zdefiniowaną strukturę. Zawiera pola identyfikujące wystawcę i podmiot, okres ważności, klucz publiczny oraz podpis wystawcy.

• Wersja: Wskazuje, z którą wersją standardu X.509 certyfikat jest zgodny (zwykle wersja 3).
• Numer Seryjny: Unikalna dodatnia liczba całkowita przypisana przez CA, która jednoznacznie identyfikuje ten konkretny certyfikat spośród wszystkich innych wydanych przez ten urząd.
• Algorytm Podpisu: Algorytm, którego CA użyło do podpisania tego certyfikatu (np. SHA-256 z RSA).
• Wystawca: Tożsamość Urzędu Certyfikacji, który zweryfikował informacje i wydał ten certyfikat. Certyfikat wystawcy dostarcza klucz publiczny używany do weryfikacji podpisu.
• Okres Ważności: Daty początkowa i końcowa, dla których certyfikat jest uważany za ważny (daty "Ważny od" i "Ważny do"). Walidator porównuje je z aktualnym czasem zgodnie z własną polityką sprawdzania zegara.
• Podmiot: Tożsamość osoby, organizacji lub urządzenia, do którego należy certyfikat. W certyfikacie TLS nazwa usługi jest zwykle umieszczana w rozszerzeniu Subject Alternative Name, na przykład DNS-ID. Common Name może zostać użyty tylko w ograniczonym trybie określonym przez klienta.
• Informacje o Kluczu Publicznym Podmiotu: To pole zawiera rzeczywisty klucz publiczny podmiotu, wraz z algorytmem, z którym klucz jest używany (np. RSA lub ECC). Certyfikat może mieć także rozszerzenia określające zastosowania klucza, ograniczenia CA, punkty publikacji CRL i adres respondenta OCSP. Rozszerzenia wpływają na zakres, w którym certyfikat może być użyty.
• Podpis Cyfrowy Wystawcy: CA podpisuje zakodowane dane certyfikatu przy użyciu swojego klucza prywatnego i określonego algorytmu. Odbiorca weryfikuje podpis kluczem publicznym wystawcy, a następnie sprawdza pozostałe warunki walidacji. Podpis nie szyfruje certyfikatu i nie zastępuje sprawdzenia nazwy usługi ani statusu.

Łańcuch zaufania i walidacja

Łańcuch zaufania łączy certyfikat końcowy z certyfikatem pośrednim i zaufaną kotwicą. System operacyjny lub przeglądarka ma własny magazyn zaufanych głównych urzędów CA. Walidator buduje ścieżkę i sprawdza podpisy, ograniczenia CA, zastosowania kluczy, nazwy, okresy ważności oraz status unieważnienia zgodnie z polityką.

Oto proces weryfikacji krok po kroku, gdy odwiedzasz bezpieczną stronę internetową:

1. Prezentacja: Twoja przeglądarka łączy się z 'https://www.przyklad.pl', a serwer przedstawia swój certyfikat SSL/TLS. Nazwijmy go "Certyfikatem Końcowym".
2. Pierwsza Kontrola: Przeglądarka bada pole "Wystawca" w Certyfikacie Końcowym. Widnieje tam na przykład "Przykladowy Pośredni Urząd CA". Sprawdza również, czy nazwa usługi pasuje do identyfikatora w certyfikacie.
3. Podążanie za łańcuchem: Przeglądarka sprawdza magazyn zaufanych głównych CA. "Przykladowy Pośredni Urząd CA" nie znajduje się na tej liście, więc serwer może przedstawić również jego certyfikat. Przeglądarka analizuje ten certyfikat jako kolejny element ścieżki. Certyfikat serwera nie musi zawierać certyfikatu głównego, ponieważ klient przechowuje kotwicę lokalnie.
4. Druga Kontrola: Przeglądarka patrzy na pole "Wystawca" w certyfikacie "Przykladowego Pośredniego Urzędu CA". Ten z kolei informuje, że został wydany przez "Przykladowy Główny Urząd CA". Przeglądarka weryfikuje również podpis na Certyfikacie Końcowym, używając klucza publicznego z certyfikatu Pośredniego Urzędu CA, i sprawdza, czy certyfikat pośredni może wystawiać certyfikaty.
5. Kotwica Zaufania: Przeglądarka ponownie sprawdza swoją listę zaufanych Głównych Urzędów CA. Tym razem znajduje na niej "Przykladowy Główny Urząd CA". Traktuje go jako kotwicę zaufania zgodnie z własną konfiguracją. Następnie używa klucza publicznego z zaufanego certyfikatu Głównego Urzędu CA (który już posiada) do weryfikacji podpisu cyfrowego na certyfikacie Pośredniego Urzędu CA.
6. Zaufanie ustanowione: Jeśli podpis certyfikatu pośredniego jest ważny, ograniczenia CA są spełnione, a wystawcą jest zaufana kotwica, przeglądarka może zaakceptować ścieżkę. Następnie sprawdza podpis certyfikatu końcowego, nazwę usługi, okres ważności i status unieważnienia. Interfejs może wskazać poprawne połączenie. Walidacja obejmuje także zastosowanie klucza i ograniczenia długości ścieżki.

Hierarchiczna struktura od głównego CA przez jeden lub więcej pośrednich CA do certyfikatu końcowego pozwala rozdzielić role i ograniczyć liczbę kluczy głównych przechowywanych jako kotwice zaufania. Akceptacja zależy od poprawnej walidacji całej ścieżki. Walidator sprawdza także, czy każdy certyfikat jest dopuszczony do swojej roli i zamierzonego zastosowania. Sam poprawny podpis nie ustanawia zaufania, gdy nie zgadza się nazwa, polityka, czas lub zastosowanie klucza.

Unieważnienie certyfikatu

Jeśli klucz prywatny dla 'www.przyklad.pl' zostanie ujawniony, CA może unieważnić certyfikat przed datą wygaśnięcia. Oprogramowanie sprawdza informację o statusie przy użyciu CRL lub OCSP, zależnie od obsługiwanej polityki.

Lista Unieważnionych Certyfikatów (CRL)

CRL to lista opublikowana i podpisana cyfrowo przez CA, zawierająca numery seryjne certyfikatów unieważnionych przed wygaśnięciem. Przeglądarka pobiera listę z punktu publikacji wskazanego przez CA, a następnie sprawdza podpis, zakres i daty listy oraz obecność numeru seryjnego.

Ograniczenia: Listy CRL mogą być duże i kosztowne do pobrania. Są publikowane zgodnie z harmonogramem CA, na przykład co 24 godziny, dlatego między ujawnieniem klucza a publikacją kolejnej listy może wystąpić opóźnienie. Klient powinien sprawdzać także okres ważności listy i jej numer, aby wykryć nieaktualny dokument.

Protokół Statusu Certyfikatu Online (OCSP)

OCSPogranicza potrzebę pobierania całej listy CRL. Przeglądarka wysyła do respondenta CA zapytanie zawierające identyfikator certyfikatu i otrzymuje podpisaną odpowiedź. Odpowiedź wskazuje status 'dobry', 'unieważniony' lub 'nieznany' oraz zawiera informacje o czasie obowiązywania odpowiedzi. Walidator sprawdza podpis odpowiedzi, identyfikator respondenta i jej aktualność. Samo wysłanie zapytania nie zmienia statusu certyfikatu. Jeśli responder nie odpowiada, zachowanie klienta zależy od jego polityki i konfiguracji.

OCSP Stapling: W klasycznym modelu przeglądarka może wysyłać zapytania statusowe do CA, co ma wpływ na prywatność i wydajność. W OCSP Stapling serwer WWW okresowo pobiera podpisaną odpowiedź dla własnego certyfikatu, a następnie dołącza ją do wymiany TLS. Przeglądarka może sprawdzić odpowiedź przekazaną przez serwer bez osobnego zapytania do respondenta CA.

Poziomy walidacji certyfikatów SSL/TLS

Certyfikaty mogą różnić się zakresem weryfikacji podmiotu. Typ walidacji wynika z procedur zastosowanych przez CA przed wydaniem certyfikatu. W praktyce wyróżnia się trzy główne poziomy:

• Walidacja Domeny (DV - Domain Validated):Jest to najbardziej podstawowy poziom walidacji. CA weryfikuje jedynie, czy wnioskodawca kontroluje nazwę domeny, dla której ubiega się o certyfikat. Weryfikacja może wykorzystywać wyzwanie HTTP, rekord DNS albo TLS-ALPN. Niektóre CA dopuszczają także wiadomość na kontrolowany adres e-mail. Dokładne metody zależą od CA. Certyfikat może być użyty w połączeniu TLS zapewniającym szyfrowanie, ale sam nie potwierdza tożsamości prawnej operatora strony. Let's Encrypt to słynny dostawca darmowych certyfikatów DV. Kontrola domeny nie oznacza zatwierdzenia treści ani bezpieczeństwa usługi.
• Walidacja Organizacji (OV - Organization Validated): Wiąże się z bardziej gruntownym procesem weryfikacji. CA wymaga od wnioskodawcy dostarczenia dokumentacji potwierdzającej prawne istnienie i fizyczną lokalizację jego organizacji. Nazwa organizacji jest umieszczana w certyfikacie, co zapewnia dodatkową informację dla odbiorców, jeśli klient ją wyświetla.
• Rozszerzona Walidacja (EV - Extended Validation): CA stosuje bardziej rozbudowaną procedurę zgodną z wytycznymi branżowymi. Obejmuje ona weryfikację prawnego, operacyjnego i fizycznego istnienia organizacji oraz prawa do korzystania z domeny. Historycznie przeglądarki wyświetlały nazwę organizacji na zielonym pasku dla certyfikatów EV, lecz większość współczesnych przeglądarek zrezygnowała z tego wyróżnienia. EV opisuje procedurę weryfikacji i nie gwarantuje bezpieczeństwa samej usługi.

PKI i certyfikaty cyfrowe wspierają uwierzytelnienie podmiotów, ochronę kluczy oraz sprawdzanie statusu certyfikatów. Bezpieczeństwo zależy od poprawnej walidacji ścieżki, zgodności nazw, aktualności danych oraz ochrony kluczy prywatnych. Operatorzy muszą utrzymywać magazyny zaufania i wycofywać klucze przejęte albo przestarzałe.