 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:
- Tworzymy własny urząd i dbamy o to, żeby jego certyfikat był na tyle
powszechnie dostępny, że jego ewentualne sfałszowanie jest widoczne w
sposób oczywisty
- Korzystamy z któregoś z publicznie uznanych urzędów certyfikacyjnych.
Oto adresy niektórych:
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ść.
|