Infrastruktura kluczy publicznych UMK

Daniel Rychcik
16-04-2001

0. Wstęp

Dokument ten opisuje politykę certyfikacji podmiotów należących do UMK w ramach PKI, narzędzia stosowane w tym celu oraz zasady używania certyfikatów. Nie jest on podręcznikiem dla użytkownika, ani instrukcją aplikacji, jednak użytkownicy powinni się z nim zapoznać przed wdrożeniem, lub przystąpieniem do PKI UMK.

1. Cele i założenia

Głównym celem projektu PKI dla Uczelni jest zapewnienie użytkownikom (zarówno pracownikom jak i studentom) bezpiecznej i autoryzowanej korespondencji oraz serwisów WWW. Możliwe zastosowania to:

• Wymiana korespondencji między prowadzącymi zajęcia (np. zadania egzaminacyjne).
• Dostarczanie studentom wyników egzaminów
• Dostarczenie studentom baz danych o nich samych z dostępem autoryzowanym przy użyciu certyfikatów (np. dane o stypendiach)
• ...

Jednym z założeń naszego projektu PKI było znalezienie kompromisu między maksymalnym bezpieczeństwem, a uniwersalnością i elastycznością rozwiązań. Zdecydowaliśmy się skierować bardziej w tym drugim kierunku. Co za tym idzie, przykładowo procesy rejestracji i wydawania certyfikatów są uproszczone, natomiast rozbudowany jest schemat nazewnictwa obiektów. Innym przykładem jest rezygnacja z instytucji RA (Registration Authority) - uznaliśmy, że i tak każdy system jest na tyle bezpieczny, na ile odpowiedzialny jest administrator.

Nasz projekt uwzględnia możliwość dopasowania struktury nazewnictwa do indywidualnych warunków każdego Wydziału. Realizowane jest to na etapie programu instalacyjnego, który większość niezbędnych danych pobiera z otrzymanego "z góry" certyfikatu. Pozwala to na stworzenie różnych hierarchii certyfikatów:

Weźmy na przykład nasz Wydział: tu struktura jest w miarę przejrzysta - główny podział to studenci, pracownicy naukowi i administracja. Można ewentualnie wydzielać studentów matematyki i informatyki, ale jest to raczej przerost formy nad treścią. Inna sytuacja występuje natomiast na Wydziale Filologicznym - tam jako główną strukturę należy raczej przyjąć podział według języka, a dopiero potem wydzielić studentów i pracowników - nasza aplikacja sprawdzi się także w takiej sytuacji.

Projekt nie jest zresztą nakierowany wyłącznie na wydziały UMK - w ten sam sposób można podejść np. do Rektoratu, czy administracji akademików. W tym wypadku widać nawet większą konieczność użycia technik bezpiecznej komunikacji, np. w momencie, gdy kierownictwo akademika przesyła listy płatnicze na Wydziały!

Ważną decyzją, którą należy podjąć przed zaprojektowaniem PKI dla instytucji jest kwestia dostępu do certyfikatów. My uznaliśmy, że Uczelnia jest jednostką z natury otwartą na świat, zatem certyfikaty pracowników i studentów powinny być dostępne publicznie.

Innym problemem jest sprawa certyfikatu głównego (Root CA) - użycie własnego jest oczywiście tańsze i takie rozwiązanie proponujemy w projekcie, jednak bez większych zmian można system rozbudować tak, aby główny certyfikat UMK był podpisany przez któryś z głównych, uznanych urzędów certyfikacyjnych. Ważne jest tylko, aby taką decyzję podjąć przed rozpoczęciem wdrażania PKI.

Oczywiście wprowadzenie PKI na Uczelni nie oznacza, że natychmiastowo wszystkie serwery muszą działać przez protokół SSL, poczta musi być szyfrowana itp. Usługi o znaczeniu drugorzędnym mogą być równolegle dostępne przez zwykłe protokoły, które są w większości przypadków szybsze. Należy jednak zalecać pracownikom, aby w sprawach urzędowych używali co najmniej technik podpisu cyfrowego, a najlepiej również szyfrowali wiadomości.

2. Zasady nazewnictwa obiektów

2.1. Drzewo certyfikacji

Obiekty podlegające certyfikacji umieszczone są w ścile zdefiniowanej strukturze opartej o notację ASN. Podstawowe założenia tej struktury to:

• Hierarchia obiektów jest oparta wyłącznie o pola O (Organization) i OU (Organizational Unit), przy czym dopuszczamy tylko jeden atrybut O na dowolnym poziomie hierarchii (w naszym przypadku zawsze O=UMK).
• Pola C (Country) i L (Location) mają znaczenie pomocnicze i nie są związane z hierarchią nazw. Takie rozwiązanie jest podyktowane sytuacją: zdarza się, że na Wydziałach czasowo pracują profesorowie z innych krajów, lub nawet pracują zdalnie przez sieć, ale muszą być autoryzowani w obrębie struktury.
• Główny identyfikator obiektu jest zawarty zawsze w polu CN (Common Name). Jego interpretacja jest ściśle określona (patrz niżej), jednak regułą jest, że jest to pewien krótki identyfikator jednoznacznie wyznaczający obiekt w obrębie danego poziomu hierarchii.
• Pole UN (Unstructured Name) ma charakter pomocniczy i zawiera pełną (długą) nazwę obiektu.
• Każdy obiekt ma obowiązkowy atrybut Email - jego interpretacja jest zależna od typu certyfikatu.

Przykładowa struktura obiektów w ramach naszego Wydziału mogłaby wyglądać następująco:

Rys.1 Schemat struktury nazewnictwa obiektów.

2.2. Nazwa wyróżniająca obiektu

Pola C, L, O, OU i CN tworzą razem obiekt DN (Distinguished Name). Powinien on zawsze być unikalny w obrębie całej hierarchii certyfikatów. W przeciwnym wypadku mogą pojawić się niejednoznaczności w identyfikacji. Jest to m.in. powodem przyjęcia w certyfikatach e-mailowych identyfikatora użytkownika jako CN (zamiast np. imienia i nazwiska - przykład: dwóch Piotrów Wiśniewskich na naszym Wydziale :).

2.3. Typy certyfikatów i interpretacja niektórych pól

Certyfikaty można podzielić na kilka typów w zależności od przeznaczenia i możliwych zastosowań:

2.3.1. Certyfikaty obiektów końcowych

• email - certyfikat służący do wymiany bezpiecznej poczty (fachowo nazywany S/MIME Certificate). Interpretacja pól w certyfikacie tego typu jest następująca:
  • DN - identyfikator użytkownika
  • Email - adres e-mail, którego dotyczy certyfikat
  • UN - Imię i nazwisko właściciela certyfikatu (dla certyfikatów indywidualnych), lub nazwa instytucji.
• server - certyfikat serwera SSL. Interpretacja pól w DN:
  • DN - pełny adres DNS serwera (np.  www-local.mat.uni.torun.pl). Co ważne: nie jest to pełny adres URL, taki jak np.  https://www-local.mat.uni.torun.pl/~dziekanat!
  • Email - adres administratora serwera, lub osoby odpowiedzialnej za właściwe używanie certyfikatu.
  • UN - pełna nazwa serwera (np.  Serwer Lokalny Wydziału Matematyki i Informatyki UMK).
• client - certyfikat klienta SSL służący do weryfikacji tożsamości użytkownika przy dostępie do zdalnych zasobów. Interpretacja pól w DN jest identyczna jak dla certyfikatów pocztowych.

2.3.1. Certyfikaty urzędów certyfikacyjnych niższego rzędu.

• sslCA - certyfikat CA upoważnionego do wystawiania certyfikatów typu client i server.
• emailCA - certyfikat CA upoważnionego do wystawiania certyfikatów typu email.
• ssl_emailCA - certyfikat CA łączącego te dwie funkcje

W certyfikatach CA dodatkowe pola w DN mają zawsze identyczne znaczenie:

• DN - nazwa skrótowa CA (np. ca_UMK)
• Email - adres e-mail administratora Urzędu.
• UN - pełna nazwa CA (np. Urząd Certyfikacyjny WMiI).

Dla certyfikatów CA podrzędnych określony jest zawsze jeden dodatkowy atrybut OU który określa nazwę podjednostki organizacyjnej, dla której tworzymy nowy urząd.

3. Narzędzia

3.1. Przeglądarki WWW

Nasz projekt zakłada, że użytkownicy korzystają z następujących wersji najpopularniejszych przeglądarek WWW:

• Netscape Navigator 4.x (Netscape Messenger) - wybraliśmy tą wersję, gdyż jest najszerzej dostępna, sprawdzona i zawiera stabilną (choć czasami nieco toporną w użyciu) implementację mechanizmów PKI. Zrezygnowaliśmy z zajmowania się wersją 6.0 przeglądarki, gdyż jest ona jeszcze bardzo niedopracowana i ma ogromne wymagania sprzętowe. Jednak ze wstępnego rozeznania wynika, że obsługa certyfikatów nie zmieniła się w niej zbytnio.
• Internet Explorer 5.x (Outlook Express) - tu sytuacja była nieco odwrotna - ilość błędów w implementacji PKI oraz ciągle odkrywanych luk w zabezpieczeniach wersji 4.x Explorera spowodowały, że zrezygnowaliśmy całkowicie z zajmowania się tą wersją przeglądarki i skupiliśmy się na aktualnej.

Wyżej wymienione programy są szczegółowo opisane w dokumentacji i stanowiły platformę testową dla całej funkcjonalności naszej aplikacji. Nie wyklucza to jednak używania PKI również w innych programach pocztowych i przeglądarkach - użytkownik musi jednak w takiej sytuacji sam nauczyć się importowania certyfikatów i innych czynności związanych z bezpieczną komunikacją.

3.2. Przeglądanie bazy danych przez użytkowników

Jak już napisano wyżej, wszystkie certyfikaty naszej PKI są dostępne publicznie - dowolny użytkownik może wejść na stosowną stronę WWW i mieć dostęp do sieciowego interfejsu bazy LDAP. Dostępne są funkcje wyszukiwania certyfikatów oraz importowania ich do lokalnej bazy danych w przeglądarce użytkownika.

W celu zapobieżenia ewentualnym przekłamaniom, publiczna baza danych powinna być dostępna wyłącznie przy użyciu protokołu SSL.

3.3. Aplikacja dla Urzędu Certyfikacyjnego

Najważniejszą częścią projektu jest aplikacja dla Urzędu Certyfikacyjnego. Jest ona dostępna za pośrednictwem przeglądarki WWW, używa jednak połączeń szyfrowanych i certyfikatów, co daje duże bezpieczeństwo. Możliwe (i zalecanejest również skonfigurowanie na poziomie serwera WWW dostępu tylko z określonych adresów IP, lub np. wyłącznie z maszyny lokalnej (loopback).

Aplikacja umożliwia wykonywanie typowych zadań związanych z certyfikacją: wystawianie, przedłużanie certyfikatów, przeglądanie bazy danych itp. Do zarządzania bazą danych używany jest protokół LDAP, natomiast operacje na certyfikatach wykonywane są przy pomocy pakietu OpenSSL

Program jest napisany w języku PHP, co daje niemal natychmiastową przenośność aplikacji na większość platform systemowych na których dostępny jest pakiet PHP i OpenSSL. Podstawowe wymagania co do systemu operacyjnego są następujące:

• Serwer WWW z obsługą SSL i PHP
• Pakiet OpenSSL
• Serwer LDAP i programy klienckie

Bazową platformą testową dla naszego programu był system Linuxowy z procesorem 486/66MHz i 16MB pamięci. Nieco nas to zdziwiło, ale mimo faktu, że w trakcie przesyłania danych protokołem SSL wykonywane są skomplikowane obliczenia kryptograficzne, w takiej konfiguracji dało się pracować. Pozwala to wnioskować, że na dowolnej dostępnej w dzisiejszych czasach maszynie system będzie działał doskonale.

Zalecamy, aby aplikacja była dostępna pod osobnym adresem DNS - na wydziale nie otrzymaliśmy zgody na włączenie jej w DNS wydziałowy, więc znaleźliśmy alternatywę - jeden z członków zespołu ma dostęp do domeny .torun.net.pl i tam zarejestrowalismy nasza aplikacje pod adresem https://ca.torun.net.pl.

Oto pełna lista używanych przez nas pakietów oprogramowania:

• Slackware Linux - system operacyjny
• Secure Shell - dostęp do serwera z zewnątrz
• Apache - serwer WWW
• mod_ssl - moduł SSL dla Apache
• OpenSSL - darmowa implementacja SSL/TLS
• PHP 4.0 - język skryptowy głównej aplikacji
• OpenLDAP - baza danych certyfikatów
• BerkeleyDB backend dla OpenLDAP

4. Usługi

Oto podstawowe zadania Urzędu Certyfikacyjnego

• Wydawanie certyfikatów użytkownikom
• Tworzenie certyfikatów dla struktur podrzędnych
• Zarządzanie bazą danych certyfikatów
• Udostępnianie certyfikatów
• Umożliwienie weryfikacji certyfikatu
• Przedłużanie ważności certyfikatów

Warto rozróżnić dwa rodzaje terminu ważności certyfikatu. W komercyjnych zastosowaniach przyjmuje się z reguły, że okres ważności zapisany bezpośrednio w certyfikatcie jest okresem w którym można certyfikatu używać to znaczy podpisywać/szyfrować za jego pomocą dane. Natomiast okres weryfikacji danych podpisanych certyfikatem jestr z reguły dłuższy (typowo dwukrotnie). W naszym projekcie przyjęliśmy jednak, że te czasy są równe.

5. Procedury certyfikacji

5.1. Certyfikaty użytkowników końcowych

W przypadku certyfikatów e-mailowych i klienckich zasada jest prosta: użytkownik zgłasza się do Urzędu i legitymuje się odpowiednimi dokumentami tożsamości. Pracownik Urzędu po ich sprawdzeniu wystawia certyfikat i wręcza użytkownikowi dyskietkę z kluczem prywatnym i certyfikatem, po czym kasuje klucz prywatny (patrz punkt 6.).

W przypadku osobistych (wystawionych na konkretną osobę) certyfikatów e-mailowych lub klienckich sytuacja jest prosta - certyfikat dotyczy osoby, która się po niego zgłosiła. Natomiast w przypadku certyfikatów firmowych, serwerów SSL i podobnych, do CA zgłasza się reprezentant firmy z pisemnym upoważnieniem do odebrania certyfikatu.

5.2. Certyfikaty podrzędnych urzędów certyfikacyjnych

Jeśli chodzi o wystawianie certyfikatów podrzędnych CA (w naszej strukturze są to typy: emailCA, sslCA i ssl_emailCA) to obowiązują wszystkie zasady dotyczące certyfikatów serwerów, z tą różnicą, że należy szczególną wagę przywiązać do dokładnej kontroli tożsamości odbiorcy i kontroli bezpieczeństwa klucza publicznego.

5.3. Zasady kontroli tożsamości

W związku z faktem, że projektowana infrastruktura dotyczy obszaru ograniczonego geograficznie, przyjmujemu, że procedura certyfikacji wymaga osobistego stawienia się podmiotu (lub reprezentanta) w siedzibie Urzędu Certyfikacyjnego. Musi on wtedy przedstawić dokument tożsamości na podstawie którego zostanie wydany certyfikat. W zależności od sytuacji powinny to być:

• student - legitymacja studencka z wpisem na aktualny semestr
• pracownik - legitymacja pracownicza lub dowód osobisty

6. Bezpieczeństwo kluczy prywatnych  (ważne).

Nasz projekt PKI nie przewiduje żadnej formy przechowywania kopii zapasowych kluczy prywatnych - zdecydowaliśmy, że akurat w tym przypadku wybierzemy zwiększenie prywatności kosztem bezpieczeństwa danych. Zatem należy uczulić użytkowników na ten problem i zalecać trzymanie kopii klucza prywatnego w bezpiecznym miejscu (stosowna wzmianka znajduje się w oświadczeniu użytkownika certyfikatu).

7. Odpowiedzialność

7.1. Odpowiedzialność Urzędu Certyfikacyjnego

Należy podkreślić, że całe przedsięwzięcie jest z natury niekomercyjne, a certyfikaty są bezpłatne, zatem odpowiedzialność Urzędu za niezgodność danych w certyfikatach ze stanem faktycznym może być co najwyżej służbowa - odpowiedni pracownicy ponoszą konsekwencje. Urząd Certyfikacyjny nie ponosi odpowiedzialności finansowej za żadne czynności wykonane przy użyciu zarejestrowanych przez niego certyfikatów.

Czym innym jest jednak problem udostępniania danych osobowych zawartych w certyfikatach - tutaj pracownicy CA podlegają w pełni ustawie o ochronie danych osobowych i w razie niekontrolowanego przepływu informacji obowiązuje ich odpowiedzialność karna.

Dane z bazy danych certyfikatów mogą być w szczególnych sytuacjach udostępnione uprawnionym do tego organom państwowym.

7.2. Odpowiedzialność użytkownika certyfikatu

Problem odpowiedzialności użytkownika certyfikatu jest potraktowany podobnie - jest to odpowiedzialność służbowa (w przypadku pracownika), lub regulaminowa (studenci). Można ją porównać z odpowiedzialnością za podpis złożony na dokumencie "papierowym".

Należy zwrócić uwagę na konieczność szybkiej reakcji w wypadku utraty lub kompromitacji klucza prywatnego. Jeżeli nadużycie skompromitowanego klucza zostanie dokonane przed zgłoszeniem tego faktu do Urzędu, odpowiedzialność za nie ponosi właściciel klucza.

Jeśli jednak taki klucz zostanie użyty po zaznaczeniu faktu kompromitacji w bazie CA, to odpowiedzialność spada na odbiorcę zaszyfrowanej, lub podpisanej przy jego pomocy przesyłki - w przypadku danych krytycznych podpis cyfrowy powinien być zawsze weryfikowany na okoliczność przedterminowego unieważnienia certyfikatu.