W artykule tym spróbuję przybliżyć nieco coś, co po rozwinięciu tytułowego skrótu nazywamy Infrastrukturą kluczy publicznych (Public Key Infrastructure). Opisuje on raczej idee stojące za PKI - starał się będę unikać szczegółów dotyczących konkretnych implementacji, konfiguracji pakietów typu openssl, czy OpenCA - tym zajmą się koledzy w innych artykułach.
Aby zrozumieć zasadę działania PKI należy poznać kilka podstawowych schematów i algorytmów stosowanych w kryptografii kluczy publicznych.
Istnieje wiele algorytmów szyfrowania danych - główny ich podział można skonstruować biorąc pod uwagę metodę dystrybucji klucza używanego do deszyfrowania. Pierwsza grupa to algorytmy tradycyjne (zwane symetrycznymi). Używają one tego samego klucza do kodowania i dekodowania danych. Jest to bardzo szeroka grupa algorytmów i obejmuje zarówno najprostsze, znane od wieków (szyfr Cezara,ROT13), które z reguły sprowadzają się do zamiany liter w tekście według jakiegoś ustalonego, znanego wyłącznie nadawcy i odbiorcy schematu, jak i bardziej nowoczesne algorytmy oparte na operacjach bitowych (przykład: DES,RC2,C4).
Wspólną wadą algorytmów symetrycznych jest konieczność bezpiecznego uzgodnienia klucza szyfrującego przed samą transmisją - pojawia się tu klasyczny problem "jajko czy kura" - jak uzgodnić klucz bezpiecznej komunikacji?
Pojawiły się metody pozwalające obejść ten problem, np. algorytm Diffiego-Helmanna: pozwala on na uzgodnienie poufnego ciągu znaków przy użyciu specjalnego protokołu negocjacji po "niebezpiecznym" kanale. Jednak znacznie lepszym rozwiązaniem okazały się algorytmy z kluczem publicznym. Opierają się one na tzw. problemach asymetrycznych. Typowy przykład takiego problemu to rozkład liczb na czynniki pierwsze: łatwo jest podnieść 65537 do kwadratu, ale rozłożenie 4295098369 na czynniki pierwsze już takie proste nie jest.
Na takich podstawach opierają się algorytmy asymetryczne, z których najbardziej znany to RSA. Jego idea jest taka:
Algorytm może mieć jeszcze inne zastosowanie: dodanie do tego schematu podpisu elektronicznego mogłoby wyglądać tak:
W praktyce podpis elektroniczny realizuje się (ze względu na wydajność) nieco inaczej, używając tzw. funkcji skrótu wiadomości (message digest) i szyfrując tylko jej wynik.
Oczywiście algorytmy asymetryczne mają również wady: podstawową z nich jest szybkość. W przypadku protokołu SSL nie stosuje się zatem wprost szyfrowania asymetrycznego do przesyłania danych po sieci, służy ono tylko do uzgodnienia klucza algorytmu symetrycznego (to rozwiązuje problem "jajka i kury" o którym napisałem nieco wyżej). W połączeniu z okresową renegocjacją tego klucza daje to naprawdę bezpieczny sposób komunikacji.
Cała matematyka opisana powyżej wygląda bardzo ładnie, jednak jak się okazuje to za mało. Problem pojawia się paradoksalnie w najmniej spodziewanym miejscu: klucz publiczny. Fakt, że klucze te są powszechnie dostępne nie zwalnia nas bowiem z dbania o to, żeby były one właściwe! Przykład wyjaśniający potencjalne zagrożenie:
Inna możliwość (istotna w przypadku podpisu elektronicznego) jest taka, że N celowo sfałszuje swój klucz publiczny, aby następnie zaprzeczyć, że wysłał wiadomość. Zatem nie tylko nadawca ale i odbiorca musi mieć pewność, że klucze publiczne używane w bezpiecznej komunikacji są właściwe!
Jak widać, bez dodatkowej pomocy nie da się zapobiec takim zagrożeniom. Można by co prawda założyć, że np. N i O wymienią się kluczami "z ręki do ręki" przed samą transmisją, ale to wypacza całą ideę kryptografii asymetrycznej - równie dobrze można wtedy zastosować zwykłe szyfrowanie kluczem tajnym. Problem ten nie ma na razie idealnego rozwiązania "matematycznego" ale wymyślono sposób na jego obejście. Ten sposób to:
Rozwiązanie to polega na wprowadzeniu do (i tak już skomplikowanego) schematu jeszcze jednej strony zwanej urzędem certyfikacyjnym (Certificate Authority, CA). Jest to zaufana osoba, lub instytucja przechowująca klucze publiczne osób chcących się wspólnie komunikować.
Instytucja ta również posiada swoją parę kluczy publiczny/prywatny których używa do wszystkich operacji związanych z kluczami użytkowników. Klucz CA jest albo powszechnie znany ("powszechnie" - na tyle, że jego sfałszowanie będzie łatwo widoczne), albo jego weryfikacja jest możliwa przy użyciu klucza publicznego jakiejś "ważniejszej" instytucji - o tym nieco później.
Jak zatem wygląda teraz nasz schemat?
Ufff... trochę to skomplikowane, ale naprawdę działa - w tym schemacie dziur już nie ma :) Oczywiście w praktyce nie wygląda to tak, że przy każdym e-mailu potrzebny jest kontakt z CA. Użytkownicy przechowują klucze publiczne swoich kontaktów lokalnie, w programach pocztowych. I niestety wynikają z tego...
... które pojawiają się w momencie, gdy "porządny", autentyczny certyfikat nagle takim być przestaje. Powody mogą być dwa: albo właściciel klucza przestaje być uprawniony do prowadzenia komunikacji z jego użyciem (np. pracownik odchodzi do konkurencyjnej firmy), albo sam klucz przestaje być zaufany (np. na skutek utraty bądź rozpowszechnienia klucza prywatnego). Gdyby bowiem przy komunikacji zawsze odpytywany był urząd certyfikacyjny, to problemu nie ma: usuwamy klucz z bazy i jest po sprawie. Jednak w sytuacji, gdy użytkownicy przechowują klucze publiczne na lokalnych dyskach to nie wystarczy.
Częściowym rozwiązaniem problemu jest stowarzyszenie z kluczem publicznym daty ważności. Wiadomości wysłane z użyciem klucza którego termin ważności upłynął mogą być traktowane na równi z fałszywymi. Inne rozwiązanie, to cykliczne publikowanie przez CA listy kluczy unieważnionych (Certificate Revocation Lists) - takie podejście stosuje się w obecnych implementacjach PKI.
I tyle ideologii. Teraz zajmiemy się trochę dokładniej sposobem realizacji tych wszystkich pomysłów w praktyce.
Do tej pory starałem się unikać tego słowa, jednak w końcu trzeba go użyć. Podstawowa zawartość certyfikatu to pewien klucz publiczny podpisany kluczem prywatnym urzędu certyfikacyjnego - umożliwia to realizację wyżej opisanych schematów komunikacji. Oto pełna zawartość certyfikatu:
Format certyfikatów jest ustandaryzowany. Wewnętrznie jest on binarny, lecz certyfikaty przesyła i przechowuje się z reguły w formie plików zakodowanych metodą Base64. Przykładowy certyfikat wygląda następująco:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=PL, L=Torun, O=MEN, OU=UMK,
CN=CA_UMK/Email=ca@uni.torun.pl
Validity
Not Before: Apr 11 18:41:14 2001 GMT
Not After : Jul 10 18:41:14 2001 GMT
Subject: C=PL, L=Torun, O=MEN, OU=UMK,
CN=www.umk.pl/Email=webmaster@umk.pl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:e2:00:9e:ca:d4:d7:82:47:ae:c3:e9:9d:88:85:
9c:07:28:2a:e5:c7:a7:44:42:c6:29:6e:b4:75:21:
1b:80:e1:e7:ec:b8:46:3d:b5:fb:80:f2:5d:03:ce:
cb:04:d8:f5:9a:ac:02:2b:63:2d:76:c6:f9:ee:5a:
77:f0:9c:4c:7d
Exponent: 65537 (0x10001)
X509v3 extensions:
Netscape Cert Type:
SSL Server
Netscape Comment:
Uniwersytet Mikolaja Kopernika
Netscape Base Url:
http://ca.umk.pl
Netscape CA Revocation Url:
/list.crl
Signature Algorithm: md5WithRSAEncryption
bd:ab:96:d8:37:00:83:27:ee:a3:76:5e:cc:eb:82:34:4a:ea:
f9:48:3e:8b:ab:4e:3e:f9:d3:9f:2e:e8:59:db:fc:49:73:80:
ec:d1:9f:81:25:9b:26:39:cd:a0:57:2a:49:d4:b4:dc:d3:19:
5e:a3:53:e3:4f:02:d8:0c:62:0b
Widać tu wszystkie poprzednio opisane atrybuty. Ten sam certyfikat w formie binarnej zakodowanej Base64 wygląda tak:
-----BEGIN CERTIFICATE-----
MIIC9zCCAqGgAwIBAgIBAzANBgkqhkiG9w0BAQQFADCBqDELMAkGA1UEBhMCUEwx
...
i6tOPvnTny7oWdv8SXOA7NGfgSWbJjnNoFcqSdS03NMZXqNT408C2AxiCw==
-----END CERTIFICATE-----
I w takiej formie jest akceptowany przez większość oprogramowania
używającego certyfikatów (typowo jako plik z rozszerzeniem .crt).
Inna forma dystrybucji certyfikatów to pliki PKCS#12 zawierające
zarówno klucz publiczny jak i prywatny - w tej postaci nowe certyfikaty
są dostarczane do właścicieli (chronione hasłem pliki .p12)
Czas na dokładniejsze wytłumaczenie czym są te tajemnicze "urzędy". Nazwa jest trochę myląca, tak naprawdę CA nie musi mieć postaci biura z papierkami, urzędnikami i kolejkami (chociaż nierzadko tak jest). Najważniejszą częścią urzędu jest jednak zawsze baza danych certyfikatów użytkowników oraz certyfikat urzędu służący do ich podpisywania. Zwłaszcza ten ostatni jest niezmiernie ważny - od jego bezpieczeństwa zależy działanie całej organizacji. Jeżeli ten certyfikac zostanie skradziony to praktycznie całą strukturę certyfikacji należy budować od nowa.
Część CA zajmująca się wystawianiem (czytaj: podpisywaniem) certyfikatów jest często fizycznie oddzielona od sieci zewnętrznej - w najważniejszych urzędach klucze użytkowników są wymieniane przy użyciu nośników wymiennych oraz pracownika, który te nośniki przekłada między maszynami :)
Drugim podstawowym zadaniem CA jest udostępnianie certyfikatów innym użytkownikom. Typowo realizuje się to w formie serwisu WWW, który umożliwia wyszukanie i załadowanie certyfikatu z użyciem przeglądarki.
Wszystkie opisywne 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.
Taka możliwość istnieje. Załóżmy przykładowo, że mamy dwupoziomową strukturę certyfikacji (analogicznie jak w przykładowym certyfikacie):
Oto przykładowy schemat zależności:
Urząd nie wydaje wtedy certyfikatów poszczególnym osobom w obrębie danego uniwersytetu - zamiast tego wydaje certyfikat tylko dla CA UMK. Ten z kolei może 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 matematyki UMK chce korespondować z profesorem filozofii UW. Mamy zatem następujące certyfikaty:
O=MEN,OU=UMK,OU=WMiI,CN=Student Studencki,email=...
O=MEN,OU=UW,OU=WF,CN=Profesor X,email=...
Student wysyłając list podpisuje go swoim kluczem prywatnym, dołącza certyfikat oraz wszystkie certyfikaty urzędów nadrzędnych, czyli WMiI,UMK,MEN. Tworzy w ten sposób łańcuch certyfikatów (certificate chain). Natomiast tok myślenia profesora (a raczej jego oprogramowania:) przy weryfikacji przesyłki jest następujący:
I tyle - a jeżeli na którymś etapie to rozumowanie zawiedzie (podpis się nie będzie zgadzał) to znaczy że gdzieś nastąpiło fałszerstwo.
W przykładowym certyfikacie przy nazwach obiektów pojawiły się tajemnicze symbole C,O,OU - czas wyjaśnić ich znaczenie. Otóż w standardzie certyfikatów została przyjęta konwencja nazewnictwa stosowana między innymi w LDAP i protokole X.500. Oto znaczenie niektórych z tych skrótów:
| C | Country |
| CN | CommonName |
| O | Organization |
| OU | OrganizationalUnit |
| E | |
| UN | UnstructuredName |
Atrybut OU może powtarzać się kilka razy i opisuje wtedy strukturę organizacji (licząc od strony wyższych poziomów). Atrybut UN (opcjonalny) opisuje nazwę obiektu w formie "luźnej", w przeciwieństwie do CN który z reguły ma jakąś ustaloną formę, np imię+nazwisko, email, adres WWW.
Przyjęto kilka reguł dotyczących wartości tych atrybutów z których najważniejsza jest chyba ta, że certyfikat bezpiecznego serwera WWW musi w polu CN zawierać adres serwera w postaci www.serwer.org. W przeciwnym wypadku większość przeglądarek wypisze ostrzeżenie przy wejściu na strony udostępniane z danej maszyny.
Tworząc własną implementację PKI mamy do rozwiązania wiele problemów natury innej niż techniczne. Bardzo ważną (jeśli nie najważniejszą) jest sformułowanie odpowiedniej tzw. polityki certyfikacji (certification policy). Musi zawierać ona szczegółowe zasady wystawiania, cofania, udostępniania certyfikatów, określać zakres i formę odpowiedzialności za ich niewłaściwe używanie, wzory stosownych oświadczeń, instrukcje użytkowania certyfikatów, jednym słowem mnóstwo papierkowej roboty, która jednak tutaj jest zdecydowanie potrzebna.
Wszystko to wiąże się faktem, że jeżeli już organizujemy urząd certyfikacyjny to po prostu z reguły mamy co chronić - należy zatem dopełnić wszystkich formalności.
Jednym z takich problemów jest np. kwestia przechowywania kluczy prywatnych odpowiadających certyfikatom. Możliwe są zasadniczo dwa rozwiązania:
Tak naprawdę żadne z tych rozwiązań nie jest doskonałe - wyboru należy dokonać w zależności od sytuacji.
Jednym z podstawowych zastosowań certyfikatów jest przesyłanie danych przy pomocy protokołu SSL (patrz inny artykuł w tym numere L+). Stosowany on jest na przykład przy udostępnianiu ważniejszych stron WWW. Pozwala to na realizację usług takich jak www-email bez niebezpieczeństwa podsłuchania prywatnych informacji przez osoby niepożądane. Można w ten sposób rozwiązać np. dostęp do usług płatnych, elektronicznych publikacji itp. - serwery WWW pozwalają dokładnie zdefiniować uprawnienia na poziomie pojedynczego katalogu/dokumentu.
Po dodaniu do tego schematu autoryzacji klienta możliwa jest realizacja takich zadań jak e-banking - istnienie powszechnie uznawanych urzędów certyfikacyjnych pozwala na traktowanie certyfikatu na równi z podpisem tradycyjnym.
Kolejnym zastosowaniem jest oczywiście poczta elektroniczna - właściwie wszystkie ważniejsze programy pocztowe pozwalają na podpisywanie i/lub szyfrowanie wiadomości z użyciem certyfikatów.
Trochę mniej znanym zastosowaniem PKI są tak zwane time-stamps - stosowane w sytuacji, gdy wymagane jest niezależne potwierdzenie wykonania pewnej operacji w ściśle określonym momencie - działają tu te same mechanizmy kryptograficzne, które zostały opisane na początku artykułu.
Inną ciekawą dziedziną jest udostępnianie zasobów ośrodków obliczeniowych - np. w projekcie obliczeniowym EuroGrid certyfikaty stosowane są do autoryzacji pracowników chcących uruchamiać swoje obliczenia na komputerach w całej Europie.
Jeszcze na koniec kilka słów o konkretnych pakietach związanych z implementacją PKI. Większość powszechnie używanego oprogramowania dostępna jest na licencji GNU.
Pakiet ten jest niezbędny jeśli chcemy przetwarzać certyfikaty: tworzyć, modyfikować itp. Zawiera narzędzia do konwersji między różnymi formatami certyfikatów oraz biblioteki do języka C.
Właściwie wszystkie używane obecnie programy wspierają protokół SSL. Za wzorcową była zawsze uważana implementacja SSL w Netscape Navigatorze. Jednak Internet Explorer jest pod tym względem trochę bardziej przyjazny, nie tylko dla zwykłego użytkownika, ale i dla programisty chcącego oprogramować PKI we własnym zakresie - ma znacznie czytelniejszą diagnostykę błędów w certyfikatach oraz wyswietla np. lancuchy certyfikatow w bardzo czytelnej formie:
Niestety i tym zakresie firma z Redmond zdecydowanie przedkłada łatwość obsługi ponad zgodność ze standardem i bezpieczeństwo - zdarza się, że certyfikaty wygenerowane według wszelkich zasad prawidłowo uznawane są za błędne. Bodajże w dokumentacji stunnela podany był przykład rażących zaniedbań IE przy przechowywaniu certyfikatów. No, ale nie to jest tematem :)
Pozostałe "duże" przeglądarki: Opera, Konqueror, Links, również wspierają SSL. W Lynxie niestety chyba nie jest ono planowane.
Podstawowym narzędziem w tej dziedzinie jest pakiet mod_ssl - napisany przez autora OpenSSL-a moduł do Apache'a wspierający bezpieczną komunikację. Jest to najczęściej stosowana kombinacja, jednak nie jedyna. Istnieją komercyjne serwery obsługujące SSL - jednym z bardziej znanych jest Stronghold. Istnieje również wersja Apache'a rozprowadzana z wbudowanym modułem mod_ssl.
Stunnel jest ciekawym pakietem pozwalającym na bezpieczne używanie programów nie przystosowanych przez autorów do bezpiecznych połączeń. Pozwala on na zbudowanie połączenia szyfrowanego, które po stronie klienta "udaje" zwykłe gniazdo TCP/IP. Jedną z częściej stosowanych możliwości jest uruchomienie w ten sposób serwera pocztowego imap. Więcej o stunnelu znajdzie czytelnik w osobnym artykule w tym numerze Linux+.
Najbardziej znaną (i chyba najdynamiczniej rozwijającą się) aplikacją realizującą zadania urzędu certyfikacyjnego jest OpenCA. Jednak w zastosowaniach komercyjnych aplikację taką często pisze się od nowa, co pozwala na lepsze przystosowanie do specyfiki konkretnej sytuacji.
Oprócz oprogramowania podstawowego przydają się także pakiety pomocnicze, np. do przechowywanie certyfikatów typowo używany jest OpenLDAP, ze względu na naturalnie pasującą hierarchię i strukturę nazw.
Student V roku matematyki UMK, programista (Java), administrator systemów UNIX-owych. Hobby: gitara.