PKI - Infrastruktura klucza publicznego

Użytkownik źródłowy szyfruje informację, używając klucza publicznego odbiorcy. Informacja przyjmowana przez odbiorcę jest deszyfrowana kluczem prywatnym. Użytkownicy mogą dysponować szeregiem par kluczy prywatnych i publicznych w celu uzyskania możliwości utrzymywania poufnej komunikacji z rozłącznymi grupami innych użytkowników systemu informatycznego.

Przy takim sposobie rozprzestrzeniania par kluczy zasadnicze znaczenie ma metoda administrowania tymi kluczami i sposób ich używania. Jest to moment, w którym do gry wchodzi PKI (Public Key Infrastructure) – infrastruktura kluczy publicznych umożliwiająca centralne tworzenie, dystrybucję, śledzenie i odwoływanie kluczy. PKI zapewnia zarządzanie kluczami oraz certyfikatami stosowanymi w kryptografii klucza publicznego. PKI można określić jako zbiór sprzętu, oprogramowania, reguł oraz procedur niezbędnych do tworzenia, zarządzania, przechowywania i dystrybucji certyfikatów opartych na kryptografii z kluczem publicznym.

Hierarchia CA

PKI składa się zazwyczaj z pięciu podstawowych komponentów:

• CA (Certification Authorities) – wydawcy certyfikatów, przydzielającego i odbierającego certyfikaty;
• ORA (Organizational Registration Authorities) – ciała poręczającego za powiązania pomiędzy kluczami publicznymi, tożsamość posiadaczy certyfikatów oraz inne atrybuty;
• Posiadaczy certyfikatów, którym wydawane są certyfikaty i którzy mogą podpisywać dokumenty cyfrowe;
• Klientów, którzy zatwierdzają cyfrowe podpisy oraz ich ścieżki certyfikowania prowadzące od znanych publicznych kluczy zaufanych CA;
• Katalogów przechowujących i udostępniających certyfikaty oraz listy certyfikatów unieważnionych (CRL – Certificate Revocation List).

Właściwie zaimplementowana infrastruktura klucza publicznego powinna wymuszać uaktualnienie klucza w regularnych odstępach czasu, określanych przede wszystkim przez wymagania systemu ochrony danej organizacji, a nie przez decyzje komercyjne. Uaktualnianie klucza powinno być także pod całkowitą kontrolą administratora PKI.

Zarządzanie kluczem nakłada znaczące obciążenie na organizację, ponieważ wymaga czegoś więcej niż tylko oprogramowania serwera tworzącego i dystrybuującego certyfikaty cyfrowe. W zakresie PKI ratyfikowano już odpowiednie standardy pozwalające na tworzenie kompatybilnych systemów PKI.

Standard X.509 stanowi powszechnie akceptowaną podstawę infrastruktury PKI, definiującą formaty danych oraz procedury związane z dystrybucją kluczy publicznych za pomocą certyfikatów podpisanych cyfrowo przez CA.

Certyfikat X.509 V3. Każdy certyfikat zawiera trzy główne pola: ciało certyfikatu, algorytm podpisu i podpis uwierzytelniający. Ciało certyfikatu zawiera numer wersji, numer seryjny, nazwy wydawcy oraz jednostki, której certyfikat dotyczy, klucz publiczny związany z tą jednostką oraz termin ważności. Może ono zawierać rozszerzenia, które są opcjonalnymi, unikatowymi polami identyfikującymi, wiążącymi dodatkowe atrybuty z użytkownikami lub kluczami publicznymi. Algorytm podpisu to algorytm używany przez CA do podpisania certyfikatu. Podpis uwierzytelniający jest podpisem cyfrowym potwierdzającym autentyczność certyfikatu.

CRL X.509 V2. W momencie wydawania certyfikatu zakłada się jego wykorzystywanie przez cały okres ważności. Jednakże różne okoliczności mogą spowodować utratę ważności certyfikatu przed upłynięciem tego okresu. Do takich okoliczności mogą należeć: zmiana nazwy, zmiana powiązania pomiędzy daną jednostką a CA (na przykład pracownik przestaje pracować w danej organizacji) oraz ujawnienie lub podejrzenie ujawnienia odpowiadającego certyfikatowi klucza prywatnego. W takich okolicznościach CA powinien odwołać certyfikat.

X.509 definiuje jedną z metod unieważniania certyfikatów. Metoda ta wymaga od każdego CA okresowego wydawania podpisanej elektronicznie struktury danych pod nazwą listy certyfikatów unieważnionych (CRL – Certificate Revocation List). CRL jest podpisywana przez CA i udostępniana publicznie. Każdy unieważniony certyfikat jest identyfikowany w CRL na podstawie jego numeru seryjnego. System wykorzystujący certyfikaty nie tylko sprawdza podpis certyfikatu oraz jego ważność, ale także sprawdza, czy numer seryjny certyfikatu znajduje się na aktualnej CRL. Znaczenie określenia „aktualna” może zależeć od lokalnej polityki, ale zwykle oznacza ostatnio wydaną CRL. CRL wydawana jest regularnie w określonych interwałach czasowych. Przewidziano także wydanie nadzwyczajne w celu przyspieszenia zawiadomienia o fakcie ujawnienia klucza prywatnego.

Zaletą metody unieważniania za pomocą CRL jest możliwość rozprowadzania jej w dokładnie taki sam sposób, jak samych certyfikatów: poprzez dowolne systemy komunikacyjne i serwery. Jedyną wadą tej metody jest ograniczenie dokładności czasowej unieważnienia do częstotliwości wydawania CRL.

Podstawowe elementy i funkcje systemu PKI

Protokoły Hybrid Auth i XAuth

1. Serwer certyfikatów – platforma do generowania, obsługi i zarządzania certyfikatami oraz łączenia ich z odpowiednimi kluczami publicznymi – zarówno dla podpisów, jak i szyfrowania danych. Wykonuje on także – na żądanie lub w regularnych odstępach czasu – odnawianie certyfikatów. Należy mieć na uwadze to, że w celu zapewnienia niezaprzeczalności klucze prywatne nie są obsługiwane przez ten serwer.
2. Katalog – repozytorium wszystkich informacji publicznych dotyczących PKI, w tym certyfikatów kluczy publicznych, listy odwołanych certyfikatów (CRL – Certificate Revocation Lists), certyfikaty wydawców certyfikatów (CA) itp… Ten element infrastruktury jest krytyczny w sensie dostępności i często ma postać rozproszoną. Niezbędna tu jest kompatybilność z protokołem LDAP (Lightweight Directory Access Protocol).
3. System odwołań – możliwość odwoływania klucza w celu uniemożliwienia dostępu do szyfrowania i funkcji podpisu użytkownikom pozbawionym tego prawa (np… Z powodu zmiany funkcji w organizacji lub zmiany miejsca pracy). Listy unieważnionych certyfikatów (CRL) powinny być obsługiwane automatycznie i dystrybuowane regularnie w całym systemie, w celu zapewnienia wiarygodności certyfikatów.
4. Oprogramowanie po stronie klienta – jeżeli wszystkie powyższe funkcje są w pełni implementowane przez PKI, to do ich wykorzystania jest niezbędny odpowiedni interfejs po stronie klienta (na PC). Oprogramowanie może mieć formę specjalnego klienta PKI, dostarczanego przez dostawcę usług PKI, lub różnego rodzaju aplikacji obsługujących PKI, takich jak przeglądarki czy klienty poczty elektronicznej.

Funkcje rozwiniętych systemów PKI można ująć w następujące kategorie:

1. Generowanie kluczy – w zależności od przyjętej strategii CA para kluczy prywatny/publiczny może być generowana albo lokalnie przez użytkownika, albo przez CA. W tym drugim przypadku klucze mogą zostać dostarczone użytkownikowi w zaszyfrowanym pliku albo w postaci fizycznej (inteligentna karta albo karta PCMCIA).
2. Rejestracja – proces, za pomocą którego dana jednostka przedstawia się CA – bezpośrednio lub za pośrednictwem urzędu rejestracji (Registration Authority – RA) – zanim CA wyda jej certyfikat lub certyfikaty.
3. Certyfikowanie – proces, w którym CA wydaje certyfikat dla klucza publicznego danej jednostki, a następnie zwraca jej ten certyfikat albo udostępnia go publicznie w katalogu certyfikatów.
4. Uaktualnianie kluczy. Wszystkie pary kluczy muszą być regularnie uaktualniane (to znaczy zastępowane nowymi parami); wydawane muszą być także nowe certyfikaty. Proces ten ma miejsce w dwóch wypadkach: normalnym – po upłynięciu terminu ważności klucza, oraz wyjątkowym – jeśli klucz został ujawniony i musi być zmieniony. Użytkownik końcowy jest na ogół wyłączany z tego procesu na tyle, na ile jest to możliwe, chyba że polityka bezpieczeństwa wymaga akcji potwierdzającej z jego strony. Jeżeli takie potwierdzenie nie jest konieczne, uaktualnianie kluczy powinno być całkowicie automatyczne i transparentne dla użytkownika.
5. Historia kluczy. Ponieważ klucze są uaktualniane w regularnych odstępach czasu, dla części użytkowników niezbędny jest dostęp do danych szyfrowanych wcześniejszą generacją klucza (czy też weryfikacji podpisów „złożonych” starszą wersją klucza). Użytkownicy nie muszą przechowywać kopii wszystkich wersji klucza (przyporządkowywanie par kluczy do poszczególnych dokumentów jest czasochłonne i może prowadzić do licznych omyłek). Z tego powodu PKI zapewnia zazwyczaj środki utrzymywania pełnej historii kluczy i dostęp do odpowiedniej wersji podczas operacji deszyfrowania dokumentu czy weryfikowania podpisu.
6. Składowanie i odtwarzanie kluczy – składowanie to umożliwia utrzymywanie kopii kluczy deszyfrujących (wszystkich użytkowników), które mogą być odtworzone w razie potrzeby. Jeśli CA wygenerował i wydał parę kluczy, kopia zapasowa prywatnego klucza użytkownika może być przechowywana albo przez CA, albo przez osobny system przechowujący kopie zapasowe. Jeśli użytkownik lub jego pracodawca chce odzyskać te klucze z kopii zapasowych, PKI musi zapewnić system umożliwiający odzyskiwanie kluczy bez ryzyka ujawnienia klucza prywatnego.
7. Obsługa cechy niezaprzeczalności – idea składowania i odtwarzania stwarza pewien słaby punkt bezpieczeństwa systemu. Ponieważ potencjalnie wiele osób obsługujących PKI może mieć dostęp do klucza prywatnego, używanego do szyfrowania podpisu, to właściciel klucza może nie mieć pewności, czy poszczególne transakcje są w sposób oczywisty podpisane przez niego. Problem ten rozwiązuje się metodą utrzymywania podwójnych par kluczy dla każdego użytkownika. Para do szyfrowania danych może być składowana i odtwarzana, natomiast para używana do podpisu nigdy nie powinna opuszczać „posesji użytkownika”.
8. Certyfikowanie przechodnie (cross-certification) – certyfikat wydawany przez jednego CA drugiemu CA. Certyfikat ten zawiera publiczny klucz CA związany z prywatnym kluczem CA, służącym do podpisywania wydawanych certyfikatów. Zwykle certyfikat przechodni używany jest w celu zapewnienia systemom klienckim oraz jednostkom końcowym jednej domeny administracyjnej możliwości bezpiecznego komunikowania się z systemami klienckimi oraz użytkownikami końcowymi innej domeny administracyjnej. Jeżeli A i B certyfikowane są przez X, natomiast C przez Y, to powstaje pytanie, jak A może zaufać C? W celu uniknięcia konieczności tworzenia wielu relacji zaufania pomiędzy poszczególnymi użytkownikami PKI umożliwia zazwyczaj tworzenie wzajemnych lub jednokierunkowych relacji zaufania pomiędzy CA. Tak więc jeżeli X jest w relacji zaufania do Y, to implikuje automatycznie zaufanie A i B do C. Poza certyfikacją jeden do jednego pomiędzy dwoma CA – PKI powinna obsługiwać wielopoziomowy, hierarchiczny model CA.