Infrastruktura klucza publicznego

Celem infrastruktury kluczy publicznych PKI (Public Key Infrastructure) jest zapewnienie zaufanego i wydajnego zarządzania kluczami oraz certyfikatami. PKI jest zdefiniowana w dokumencie Internet X.509 Public Key Infracture. Wg tego dokumentu, PKI to: zbiór sprzętu, oprogramowania, ludzi, polityki oraz procedur niezbędnych do tworzenia, zarządzania,

przechowywania, dystrybucji oraz odbierania certyfikatów opartych na kryptografii z kluczem publicznym.

Główny CA jest "punktem zaufania" dla wszystkich jednostek w strukturze PKI. Jego klucz publiczny jest stosowany bezpośrednio lub pośrednio do podpisywania wszystkichcertyfikatów w strukturze PKI. Główny CA podpisuje także certyfikaty, wydawane innym strukturom PKI (jest to zazwyczaj nazywane cross-certyfication lub certyfikacją skrośną).

Liczba podległych CA jest teoretycznie nieograniczona.

Organ Zarządzania Polityką Certyfikacji (PMA - Policy Management Authority) jest ciałem, które ustala i administruje zbiorem polityk bezpieczeństwa, stosowanych w infrastrukturze, zatwierdza certyfikację innych Głównych CA i zewnętrznych CA i nadzoruje działanie Głównego CA.

Repozytoria certyfikatów, w których przechowywane są certyfikaty, listy CRL i listy organów unieważnionych (listy ARL) (ARL - Authority Revocation List) . Repozytorium musi być dostępne dla wszystkich tych, (w pewnych przypadkach, również spoza struktury danej PKI) którzy chcą wykorzystywać usługi ochrony, dostępne w aplikacjach obsługujących strukturę PKI, a co za tym idzie, informacje dotyczące struktury PKI muszą być rozpowszechniane w jednolitej formie.

Organy Rejestracji (RA) mogą służyć do wymiany niezbędnych informacji pomiędzy użytkownikiem a Organami Certyfikacji, przejmując niektóre z funkcji administracyjnych CA.

Funkcje realizowane przez PKI:

• Rejestracja. Proces za pomocą którego dana jednostka przedstawia się CA. Może to robić bezpośrednio lub za pośrednictwem zarządu rejestracji (Registration Authority - RA).

• Inicjacja. Procedura wg której, zgłaszający się otrzymują wartości (dane) potrzebne do rozpoczęcia komunikacji z PKI. Może obejmować dostarczenie klientowi systemu z kluczem publicznym lub certyfikatem CA, lub

wygenerowanie pary kluczy klienta.

• Certyfikowanie. Proces, w którym CA tworzy certyfikat i przekazuje go właścicielowi. Może go również upublicznić w magazynie.

42

• Odzyskiwanie par kluczy. Kopia zapasowa prywatnego klucza użytkownika może być przechowywana przez CA lub specjalnie powołany do tego system.

• Generowanie kluczy. Para kluczy może być generowana lokalnie przez użytkownika lub przez CA. Mogą one być dostarczone użytkownikowi w zaszyfrowanym pliku lub w postaci fizycznej (inteligentna karta).

• Uaktualnianie kluczy. Wszystkie pary kluczy muszą być regularnie uaktualniane. Należy też wydawać nowe certyfikaty. Procedura taka jest realizowana po przekroczeniu terminu ważności lub po ujawnieniu klucza.

• Certyfikowanie przechodnie. Procedura wydawania certyfikatu innemu CA. Certyfikat przechodni używany jest w celu umożliwienia systemom klienckim jednej domeny administracyjnej bezpieczne komunikowanie się z systemami klienckimi innej domeny.

• Unieważnianie. Różne okoliczności mogą spowodować przedterminową utratę ważności certyfikatu. Może to być zmiana powiązania między klientem a CA, ujawnienie lub podejrzenie ujawnienia klucza prywatnego.

Użytkownicy w systemach wykorzystujących kryptografię klucza publicznego muszą być pewni, że klucz publiczny jednostki, z którą się komunikują, rzeczywiście należy do tej jednostki. Ta pewność jest uzyskiwana przez użycie certyfikatów kluczy publicznych. Są to struktury danych łączące klucze publiczne z jednostkami, do których one należą. Powiązanie to jest osiągane dzięki zweryfikowaniu przez zaufany CA tożsamości jednostki i podpisaniu certyfikatu. Certyfikat ma ograniczony czas życia. Struktura certyfikatu musi być jednolita w całym PKI. Certyfikat jest podpisany, więc może być rozprowadzany za pomocą niezaufanych systemów komunikacyjnych. Mogą być także buforowane w niezabezpieczonych pamięciach.

Podstawowe elementy występujące w certyfikacie

• Numer wersji - numer wersji formatu certyfikatu

• Numer seryjny - numer przydzielony certyfikatowi przez CA. Unikalny w obrębie funkcjonowania CA

• Identyfikator algorytmu - określa algorytm użyty do podpisania certyfikatu i jego parametry

• Identyfikator wystawcy - nazwa CA, który wydał i podpisał certyfikat

• Okres ważności - data początku i końca ważności certyfikatu

• Użytkownik certyfikatu - określa użytkownika

• Informacja o kluczu publicznym - klucz publiczny użytkownika oraz identyfikator algorytmu, który będzie ten klucz wykorzystywał

• Rozszerzenia - informacje dodatkowe

• Podpis cyfrowy - uwierzytelnia pochodzenie certyfikatu. Funkcja skrótu jest stosowana do wszystkich pól certyfikatu (oprócz pola podpisu). Wynik haszowania jest szyfrowany kluczem prywatnym CA.

Proces poświadczania certyfikatu składa się z czterech kroków:

1. Sprawdzenie czy tożsamość nadawcy jest zgodna z opisem w certyfikacie.

2. Sprawdzenie czy żaden certyfikat na ścieżce uwierzytelnienia nie został unieważniony.

3. Sprawdzenie czy dane mają atrybuty, do których podpisujący nie jest upoważniony.

4. Sprawdzenie czy dane nie zostały zmienione od momentu ich podpisania.

Standard X.509 definiuje również metodę unieważniania certyfikatów. CA jest zobowiązany do okresowego wydawania podpisanej listy unieważnienia certyfikatu CRL (certificate revocation list). Lista ta powinna być udostępniana w publicznym miejscu. Każdy certyfikat w CRL jest identyfikowany poprzez numer seryjny.

Do dystrybucji certyfikatów można wykorzystywać różne protokoły. Mogą to być protokoły uniwersalne takie jak HTTP czy FTP. Mogą to być protokoły dedykowane takie jak LDAP. Protokół LDAP (Lightweight Directory Access Protocol) jest używany do uzyskania dostępu do usług katalogowych. Ma on ułatwiać dostęp do katalogów X.500. Jest on ukierunkowany na aplikacje zarządzające i przeglądarki. Protokół LDAP V2 jest zdefiniowany w RFC 1777.

43 Dlaczego hierarchia CA ?

Wszystkie opisywane dotąd mechanizmy są już od dawna stosowane w Sieci - ilość używanych certyfikatów można mierzyć w milionach. Oczywiście żadne pojedyncze centrum certyfikacji nie byłoby w stanie podołać obsłudze takiej liczby klientów, i to nie tylko z przyczyn technicznych (szybkość łącz, biurokracja itp.) ale również organizacyjnych. Naturalna staje się zatem potrzeba wprowadzenia pewnej hierarchii urzędów certyfikacyjnych. Przykładowa, hipotetyczna hierarchia urzędów certyfikacyjnych i związana z tym ścieżka certyfikacji została przedstawiona na rys. 5.

Rys. 5. Hipotetyczna hierarchia CA

Urząd CA MEN nie wydaje wtedy certyfikatów poszczególnym osobom w obrębie danej uczelni - zamiast tego wydaje certyfikat tylko dla CA PJWSTK, czy CA WAT. Te z kolei mogą wydawać certyfikaty dla CA jeszcze niższego poziomu, lub dla swoich pracowników. Takie podejście ma dwie zalety:

• zmniejszony ruch w sieci - do weryfikacji certyfikatu przy korespondencji w ramach jednej jednostki organizacyjnej nie jest potrzebna wiedza o CA wyższego poziomu,

• rozłożenie odpowiedzialności w sposób odpowiadający organizacji instytucji.

Jak jednak jest realizowana weryfikacja przy takiej "drzewiastej" strukturze urzędów? Załóżmy, że student Informatyki WAT chce korespondować z profesorem katedry sieci komputerowych PJWSTK.

Student wysyłając list podpisuje go swoim kluczem prywatnym, dołącza swój certyfikat oraz wszystkie certyfikaty urzędów nadrzędnych, czyli np. ITiA, WAT, MEN. Tworzy w ten sposób łańcuch certyfikatów (certificate chain) przedstawiony na rys.6. Natomiast tok myślenia profesora (a raczej jego oprogramowania:) przy weryfikacji przesyłki jest następujący:

• Student wykazał się certyfikatem wydanym przez CA ITiA - nie wiem co to jest, nie ufam mu

• Ale CA ITiA legitymuje się certyfikatem wydanym przez CA WAT (i podpis w certyfikacie się zgadza) - ale ja nadal nie wiem co to za certyfikat - nie znam tej struktury (WAT)

• Ale CA WAT legitymuje się certyfikatem wydanym przez CA MEN (i podpis się zgadza!) - o, to co innego, sam należę do struktury MEN i skoro moje CA najwyższego poziomu to zatwierdziło, to ja ten certyfikat też uznaję

Jeżeli na którymś etapie to rozumowanie zawiedzie (podpis nie będzie się zgadzał) to znaczy że gdzieś nastąpiło fałszerstwo.

44 VIII. Systemy uwierzytelniania