« poprzedni punkt |
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.
Rys. 4. Komponenty PKI
Główny CA jest "punktem zaufania" dla wszystkich jednostek w strukturze PKI. Jego klucz publiczny jest stosowany bezpośrednio lub pośrednio do podpisywania wszystkich certyfikató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:
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
Proces poświadczania certyfikatu składa się z czterech kroków:
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.
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:
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:
Jeżeli na którymś etapie to rozumowanie zawiedzie (podpis nie będzie się zgadzał) to znaczy że gdzieś nastąpiło fałszerstwo.
Rys. 6. Łańcuch certyfikatów
« poprzedni punkt |