Strona główna
Projekt
Harmonogram
Przebieg pracy
Raporty
Referaty
Dokumentacja
Linki


PKI
Kryptografia
SSL
Instalacja
mod_ssl
IMAP
Słownik




  wersja drukowalna

Infrastruktura kluczy publicznych - cele i zastosowania

Daniel Rychcik
15-04-2001

0. Wstęp

Dokument ten ma na celu zaznajomienie użytkownika z podstawowymi celami, założeniami i metodami stosowanymi w ramach PKI (Public Key Infrastructure). Opisane zostaną: zagrożenia w sieci, certyfikaty, łańcuchy certyfikatów oraz sprawy formalne związane z organizacją PKI.

Zakładamy, że Czytelnik zaznajomił się już z algorytmami stosowanymi w kryptografii asymetrycznej opisanymi w stosownym dokumencie.

1. Zagrożenia w sieci komputerowej

Cała komunikacja w sieci Internet używa jako protokołu TCP/IP (Transmission Control Protocol/Internet Protocol). Protokół ten nie zawiera żadnych mechanizmów zabezpieczających przed atakami osób nieuprawnionych takimi jak:

1.1. Podsłuchiwanie informacji

Przykład: kiedy logujemy się na zdalną maszynę używając programu telnet nasze dane (identyfikator+hasło) wędrują po Sieci otwartym tekstem - każdy, kto ma dostęp do fizycznego nośnika, lub do któregoś z routerów pośrednich może je przechwycić i następnie używać naszego konta do dowolnych innych celów. Inny przykład to przechwytywanie numerów kart kredytowych używanych do transakcji elektronicznych za pośrednictwem serwisów on-line.

1.2. Fałszowanie informacji

Przykład: wysyłamy zlecenie przelewu gotówki z naszego konta na konto kontrahenta, a ktoś "przypadkiem" dopisuje w pewnym miejscu jedno zero.

1.3. Podszywanie się

Możliwa jest sytuacja podobna: wchodzimy na stronę elektronicznego banku, a tymczasem w rzeczywistości jest to strona, która bank "udaje" i przechwytuja nasze dane takie jak numer karty kredytowej, czy hasło na konto.

1.4. Zaprzeczanie faktom

Przykład nieco bardziej skomplikowany: uzgodniliśmy z partnerem warunki pewnej umowy, wpłaciliśmy gotówkę, a on nagle zaprzecza, że jakakolwiek umowa miała miejsce - potrzebny jest odpowiednik podpisu na papierze.

2. Idea PKI

Rozwiązaniem tej sytuacji jest użycie odpowiednich metod kryptografii asymetrycznej, opisanych wcześniej. Jednak, jak wiemy, pojawia się wtedy problem dystrubycji i autentyczności kluczy publicznych stron - potrzebna jest metoda dołączania do klucza publicznego informacji o właścicielu w sposób, który uniemożliwia sfałszowanie tych informacji.

Idea jest następująca: zakładamy istnienie "trzeciej strony", której ufają obydwie strony chcące się bezpiecznie komunikować. Klucz publiczny "trzeciej strony" jest powszechnie znany (powszechnie w tym znaczeniu, że w przypadku jego sfałszowania będzie to w sposób oczywisty widoczne). Klucze publiczne (wraz z danymi) komunikujących się stron są wtedy dystrybuowane w specjalnym "opakowaniu".

Opakowanie kluczy polega na tym, że "trzecia strona" (będziemy dalej używać terminu CA (Certification Authority) wyznacza wartość funkcji skrótu dla całości klucza publicznego stron komunikujących się (wraz z danymi personalnymi), szyfruje wynik swoim kluczem prywatnym i dołącza na końcu klucza. Całość jest wtedy nazywana certyfikatem (Certificate, Public Key Certificate).

Kiedy otrzymujemy certyfikat i chcemy zweryfikować jego autentyczność wystarczy:

  • wyznaczyć wartość funkcji skrótu na danych "wewnętrznych" certyfikatu (klucz publiczny właściciela i jego dane)
  • odszyfrować skrót otrzymany wraz z certyfikatem używając klucza publicznego CA
  • porównać wyniki - jeżeli się zgadzają, to oznacza, że certyfikat jest autentyczny (czyli klucz publiczny należy rzeczywiście do osoby, której dane są zawarte w certyfikacie).

3. Certyfikaty

3.1. Idea

Certyfikat jest dokumentem elektronicznym, który identyfikuje pewną osobę, maszynę, usługę, firmę, cokolwiek - w sposób analogiczny jak np. dowód osobisty identyfikuje obywatela. Mogą się z tym wiązać pewne uprawnienia - przykładowo takim rodzajem "certyfikatu" jest prawo jazdy: uprawnia do prowadzenia pojazdów mechanicznych pewnej kategorii.

Podobieństwo do dokumentów "papierowych" jest zachowane do tego stopnia, że podobnie rozwiązana jest z reguły procedura ich wydawania. Podajmy kilka przykładów:

  • Certyfikaty o dużym znaczeniu (odpowiednik: dowód osobisty) są wydawane tylko osobiście, na podstawie potwierdzonych danych otrzymanych z wiarygodnego źródła. Takim certyfikatem może być na przykład identyfikator cyfrowy użytkownika elektronicznego systemu bankowego.
  • Wydawanie certyfikatów potwierdzających posiadanie pewnych uprawnień, bądź umiejętności może być poprzedzone weryfikacją tych umiejętności (tak jak przy egzaminie na prawo jazdy).
  • Certyfikaty o mniejszym znaczeniu mogą być wystawiane i przesyłane zdalnie, bez konieczności stawienia się użytkownika w centrum rejestracji (przykład z życia: wytwórnia wizytówek :-).

3.2. Zawartość

Certyfikat zasadniczo dzielimy na trzy części:

  • Dane właściciela certyfikatu
    W zależności może to być imię i nazwisko, nazwa firmy, adres serwera WWW, lub inne dane.
  • Klucz publiczny właściciela certyfikatu
  • Podpis instytucji zaufanej
    Jak już wiemy, jest to wartość ustalonej w standardzie funkcji skrótu (tu: MD5) wyznaczona na poprzednich dwóch elementach zaszyfrowana kluczem prywatnym instytucji zaufanej

3.3. Nazewnictwo

W przypadku danych właściciela konieczne było ustalenie pewnego standardu ich zapisywania, aby uniknąć niejednoznaczności w różnego typu certyfikatach i, związanej z nią, konieczności stworzenia kilku formatów certyfikatów. Projektanci zdecydowali się na przyjęcie standardu nazewnictwa stosowanego w normie X.501. Nie jest celem tego dokumentu opisywanie tej normy (zainteresowanych odsyłamy do odpowiedniego dokumentu RFC, jednak ustandaryzowana nazwa wygląda mniej więcej tak:

C=PL Dwuliterowy skrót nazwy kraju
L=Torun Nazwa miejscowości
O=MEN Nazwa organizacji
OU=WMiI Nazwa jednostki organizacyjnej
OU=studenci Kolejna nazwa niższego poziomu hierarchii nazw (sekcji typu OU można stworzyć więcej w zależności od potrzeb
CN=muflon Nazwa własna właściciela certyfikatu - musi być unikalna w obrębie jednostki organizacyjnej najniższego poziomu
Email=muflon@mat.uni.torun.pl Adres e-mail właściciela
UN=Daniel Rychcik Pełna nazwa właściciela - nie musi być unikalna, powinna być bardziej opisowa, niż CN

3.4. Atrybuty dodatkowe

Oprócz tych trzech części stosuje się też pewne dodatkowe atrybuty (właściwości) certyfikatu. Mogą one określać jego przeznaczenie, zawierać pewne dodatkowe informacje dla oprogramowania używającego certyfikatów takie jak:

  • typ certyfikatu - czy jest to certyfikat e-mailowy, serwera, klienta SSL itp.
  • okres ważności certyfikatu
  • nazwę CA wystawiającego certyfikat
  • zastosowanie - czy właściciel jest upoważniony do podpisywania innych certyfikatów (czy może działać jako CA)
  • komentarze - łańcuchy tekstowe zawierające dodatkowe informacje o certyfikacie.

Atrybuty dodatkowe są na równi z podstawowymi danymi certyfikatu podpisywane przez wystawcę.

3.5. Łańcuchy certyfikatów

Opisany dotąd model podpisywania certyfikatów jest "płaski" - zakłada istnienie "superurzędu" któremu wszyscy ufają. W rzeczywistości takie rozwiązanie byłoby bardzo niewygodne, zarówno ze względów organizacyjnych (wystawianie certyfikatów) jak i technicznych (utrzymywanie ogromnej bazy danych). Wprowadzono więc możliwość hierarchicznej struktury urzędów certyfikacyjnych

Dla przykładowego certyfikatu użytkownika systemu komputerowego WMiI o nazwie takiej jak w przykładzie powyżej sytuacja może wyglądać następująco:

  • Certyfikat jest bezpośrednio podpisany przez CA wydzielone dla studentów Wydziału.
  • Certyfikat tego CA jest podpisany przez certyfikat CA wydziałowego.
  • Certyfikat WMiI jest podpisany przez CA UMK
  • Certyfikat UMK jest podpisany przez CA ministerstwa
  • ... i co dalej ?!

Doszliśmy do problemu podpisywania certyfikatu głównego - aby był on zgodny ze standardem musi go ktoś podpisać. Przyjęto rozwiązanie takie, że właściciel takiego certyfikatu sam go sobie podpisuje! Opisany zbiór certyfikatów służący do ostatecznej weryfikacji nosi właśnie nazwę łańcucha certyfikatów (Certificate Chain).

Jak zatem wygląda weryfikacja certyfikatu tego rodzaju? Kiedy otrzymamy e-maila od Daniela Rychcika spod adresu muflon@mat.uni.torun.pl podpisanego certyfikatem z nazwą własną jak powyżej, musimy wykonać następujące czynności w celu sprawdzenia jego autentyczności:

  • Sprawdzić prawdziwość podpisu CA WMiI pod certyfikatem użytkownika (w tym celu musimy pobrać z sieci certyfikat CA WMiI).
  • Aby upewnić się, że pobrany certyfikat CA WMiI jest autentyczny, musimy w podobny sposób sprawdzić go, używając certyfikatu CA UMK.
  • W ten sposób możemy dojść bądź do głównego certyfikatu MEN, który z założenia znamy i mamy go zainstalowanego w systemi, albo do niższego poziomu, na którym wyrażamy już zaufanie do wystawcy.
    Przykład: będąc profesorem na WMiI wystarczy nam sprawdzenie wiarygodności podpisu do poziomu certyfikatu CA WMiI - gdybyśmy nie uznawali go za zaufany to stawiałoby pod znakiem zapytania wiarygodność naszego certyfikatu!

W praktyce certyfikaty tego typu (mocno "zagnieżdżone") rozprowadza się w postaci zawierającej wszystkie certyfikaty pośrednie aż do poziomu głównego CA - ułatwia to weryfikację i zmniejsza dodatkowy ruch w sieci.

3.6. Główni wystawcy certyfikatów.

Jeśli chodzi o urzędy certyfikacyjne najwyższego poziomu, to możliwe są dwa rozwiązania:

4. Urzędy certyfikacyjne

Wiele razy używany był dotąd termin Urząd Certyfikacyjny - czas podać precyzyjnie, co rozumiemy pod tym terminem. Urząd certyfikacyjny to pojęcie bardzo obszerne. Obejmuje ono:

  • bazę danych zawierającą właściwe certyfikaty
  • oprogramowanie umożliwiające zarządzanie certyfikatami
  • zbiór procedur ustalających szczegółowe zasady postępowania w konkretnych sytuacjach

Urząd certyfikacyjny nie musi mieć postaci fizycznego urzędu - równie dobrze może być to serwer (lub jego fragment) na którym operacje są dokonywane automatycznie. W przypadku certyfikatów o niskiej ważności proces rejestracji może być dokonywany za pomocą przeglądarki WWW.



Zbudowanie własnej struktury CA pociąga za sobą konieczność importowania w jakiś sposób certyfikatów głównych do programów klienckich. Istnieje jednak kilka powszechnie uznanych urzędów certyfikacyjnych - ich certyfikaty są domyślnie instalowane w przeglądarkach. Jeżeli zatem włączymy naszą PKI w infrastrukturę globalną (czyli nasz główny klucz będzie podpisany przez któryś z uznanych CA) to bezpieczna komunikacja będzie mogła się odbywać bez dodatkowych zabiegów.

W przypadku tego rodzaju certyfikatów mamy do czynienia z klasami certyfikatów. Polega to na tym, że urząd wystawia certyfikaty o różnej "sile" - na tej podstawie możemy różnie oceniać wiarygodność partnera. I tak, wiadomo np., że certyfikat klasy Verisign Class 3 jest darmowy i każdy może go sobie wystawić używając przeglądarki WWW. Zatem będziemy na niego patrzeć inaczej, niż na certyfikat Class 0 za którego wydanie należy zapłacić kilkadziesiąt tysięcy dolarów! Poza tym dla wyższych klas certyfikatów wystawcy z reguły gwarantują swoją odpowiedzialnośc (również finansową!) za ich wiarygodność.