Przegląd podstawowych technik kryptograficznej ochrony danych

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Infrastruktura klucza publicznego (PKI)

Wstęp
1. Mechanizm poświadczania autentyczności w PKI

1.1. Certyfikaty PKI

1.2. Struktura PKI

2. Proces certyfikacji

3. Weryfikacja certyfikatu
4. Wydawanie kluczy kryptograficznych przez urząd certyfikacji

Bibliografia

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Wstęp

Kryptografia klucza publicznego gwarantuje tajność oraz wiarygodność przesyłanych
i przechowywanych danych. Oznacza to, że nie musimy obawiać się przechwycenia
danych przez osoby niepowołane, nikt bowiem, poza adresatem, nie pozna zaszyfrowanej
treści danych. Dodatkowo możemy ufać otrzymywanym przesyłkom, ponieważ mamy
pewność co do ich autorstwa oraz co do integralności zawartych w nich treści.
Wydawałoby się więc, że kryptografia klucza publicznego kompleksowo i ostatecznie
rozwiązuje problem ochrony informacji, gdyby nie sprawa ograniczonego zaufania do
rzeczywistej tożsamości naszego rozmówcy, którą można zawrzeć w pytaniu: skąd
można mieć pewność, że osoba, z którą prowadzona jest korespondencja, jest naprawdę
tym, za kogo się podaje? Treścią niniejszego modułu jest omówienie sposobu, jaki został
przyjęty w celu rozstrzygnięcia powyższej wątpliwości.

Szczegółowe informacje dotyczące prezentowanych w niniejszym module zagadnień są
zawarte w dokumentach określających standardy kryptografii klucza publicznego
— tzw. standardach PKCS — Public Key Cryptography Standards
(

http://www.rsasecurity.com/rsalabs/default.asp

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

1. Mechanizm poświadczania autentyczności w PKI

Bezpieczeństwo danych w systemach kryptografii klucza asymetrycznego bazuje na
zaufaniu w prawdziwość klucza publicznego, chroniącego informacje. Użycie klucza
publicznego partnera korespondencji pozwala na zaszyfrowanie kierowanych do niego
danych (np. numeru karty kredytowej), utajniając je przed osobami nieposiadającymi
odpowiedniego klucza prywatnego. Podobnie, użycie klucza publicznego autora
otrzymanego przez nas kryptogramu pozwala na odszyfrowanie zawartych w nim danych,
dając pewność ich wiarygodności.

Klucz publiczny, który posiadamy i używamy do szyfrowania i deszyfracji przesyłanych
wiadomości staje się gwarantem tożsamości partnera korespondencji. Nasze
przekonanie, że komunikujemy się z daną osobą, opieramy w całości na zaufaniu do
tego, że posiadany przez nas klucz publiczny rzeczywiście należy do tej osoby. Oznacza
to, że w chwili przyjęcia przez nas czyjegoś klucza publicznego, musimy mieć pewność,
co do jego wiarygodności. Jeżeli nie istnieją odpowiednie, dodatkowe mechanizmy
uwiarygodnienia, pewność taką może dać jedynie osobiste pobranie klucza publicznego
od jego właściciela. Każda inna forma przekazania klucza — na przykład jako załącznika
do poczty elektronicznej, listu zawierającego dyskietkę czy pobrania klucza z serwera
— nie dają nam gwarancji, że nie padniemy ofiarą oszustwa. Zważywszy, że większość
partnerów, z którymi chcielibyśmy porozumiewać się w bezpieczny sposób przez Internet
nie jest nam znana osobiście (sklepy internetowe, banki, usługi internetowe) i osobista
wymiana klucza nie wchodzi w grę, konieczne stało się opracowanie sposobów
gwarantowania tożsamości partnerów bezpiecznej komunikacji. Efektem podjętych starań
jest stworzenie systemu mechanizmów poświadczania autentyczności, a także
rozpowszechniania i kontroli danych uwierzytelniających, nazywanego infrastrukturą
klucza publicznego (oznaczanego skrótem PKI, pochodzącym od angielskiej nazwy
Public Key Infrastructure).

Istota mechanizmu gwarantowania tożsamości przyjęta w PKI polega na wprowadzeniu
do procedury wymiany kluczy publicznych między dwoma stronami komunikacji trzeciego
podmiotu, do którego obydwie strony mają zaufanie i który gwarantuje prawdziwość
przekazywanych danych. Sposób, w jaki realizowane jest poświadczenie rzetelności
danych polega na umieszczeniu tych danych w obszerniejszym dokumencie, nazywanym
certyfikatem, sporządzonym i podpisanym elektronicznie przez zaufaną, trzecią stronę.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

1.1. Certyfikaty PKI

Certyfikat jest dokumentem, którego celem jest zaświadczenie autentyczności danych
podmiotu, dla którego został wystawiony i jednoznaczne powiązanie tych danych
z kluczem publicznym tego podmiotu. Dlatego też pierwsza grupa informacji, jakie
zawarte są w certyfikacie, to klucz publiczny i informacje o jego posiadaczu (rys. 1).
W przypadku, gdy certyfikat jest wydawany osobie fizycznej, powinny znaleźć się w nim
dane osobowe (imię i nazwisko) tej osoby oraz, tym razem opcjonalnie, informacje
o zatrudniającej ją instytucji (oddziale firmy: OU — ang. organizational unit i nazwie
firmy: ON — ang. organization name) oraz lokalizacji terytorialnej posiadacza (nazwie
państwa: CN — ang. country name i ewentualnej nazwie jednostki terytorialnej państwa,
takiej jak stan czy województwo: S — ang. state name). Jeżeli certyfikowana jest
instytucja, pole CN będzie zawierać jej nazwę, zaś pozostałe wymienione pola będą
zwykle puste.

Kolejna kategoria informacji zawarta w certyfikacie dotyczy samego certyfikatu, a nie
osoby certyfikowanej. Mamy tu więc przede wszystkim datę ważności certyfikatu,
określającą od kiedy do kiedy przedłożony certyfikat jest ważny, a także informację
o przeznaczeniu certyfikatu. Możliwe przeznaczenia certyfikatu to poświadczenie
autentyczności jego posiadacza jako partnera bezpiecznej komunikacji, uwierzytelnienie
poczty wysłanej przez posiadacza lub inne funkcje. Kolejną, niezmiernie ważną
informacją jest numer identyfikujący certyfikat, nadawany unikatowo dla każdego
wydawanego certyfikatu i wykorzystywany do sprawdzania, czy certyfikat nie został
czasem unieważniony (co będzie szerzej opisane w dalszej części modułu). Dodatkowo,
w certyfikacie mogą znaleźć się informacje pomagające odszukać w sieci serwery
zawierające listy unieważnionych certyfikatów.

Wymienione informacje — zarówno te, które dotyczą osoby certyfikowanej, jak i te, które
opisują certyfikat — są w trzeciej części certyfikatu uzupełniane danymi wystawcy
certyfikatu. Ostatnim elementem certyfikatu jest podpis elektroniczny sporządzony dla
wszystkich zawartych w nim danych, obejmujący również informację o algorytmie
użytym do wyznaczenia tego podpisu.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Posiadacz certyfikatu

Dane certyfikatu

Wystawca

Klucz

publiczny

Dane posiadacza

CN, OU ...

Data ważności,

ID, przeznaczenie

Podpis

Dane

wystawcy

Rysunek 1. Informacje zawarte w certyfikatach PKI

W celu ujednolicenia postaci certyfikatów, koniecznej z punktu widzenia możliwości
korzystania z nich przez różne aplikacje, ustalonych zostało kilka standardowych
formatów, określających sposób organizacji wymienionych wcześniej informacji.
Najpowszechniej stosowanym obecnie formatem zapisu certyfikatu jest format X.509,
którego podstawowe elementy zostały przedstawione w tabeli 1.

Tabela 1. Podstawowe dane określane przez format X.509 certyfikatu

Nazwa pola

Opis

Version

Informacja o wersji formatu certyfikatu (najpowszechniej stosowana
jest obecnie wersja 3, oznaczana cyfrą 2)

Serial Number

Numer certyfikatu, unikatowy w obrębie puli certyfikatów wydawanych
przez dany urząd certyfikacji

Validity

Okres ważności certyfikatu (od–do)

Subject Name

Nazwa i inne informacje o posiadaczu

Subject Name Key
Info

Klucz publiczny posiadacza oraz określenie algorytmu, którego dotyczy
wykorzystanie klucza

Issuer Name

Nazwa urzędu certyfikacji, który wydał certyfikat

Algorithm Identifier

Algorytm użyty do podpisania certyfikatu przez urząd certyfikacji

Key Usage,

Extended Key Usage

Przeznaczenie klucza zawartego w certyfikacie (definiowane jako

szyfrowanie, uwierzytelnianie, podpisywanie innych certyfikatów oraz
uwierzytelnianie serwera lub klienta, aplikacji, podpisywanie poczty
i inne)

CRL Distribution

Points

Adresy sieciowe, pod którymi można uzyskać aktualną listę

unieważnionych certyfikatów

1.2. Struktura PKI

Rolę strony poświadczającej autentyczność danych użytkowników systemu pełnią w PKI
główne urzędy certyfikacji (ang. Root Certificate Authority). Są to instytucje prywatne

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

lub rządowe, obdarzone przez użytkowników zaufaniem co do rzetelności wykonywanych
przez nie usług. U źródeł tego zaufania leży przekonanie, że wydanie każdego certyfikatu,
poświadczającego prawdziwość danych jakiegoś podmiotu, jest poprzedzone drobiazgową
i rzetelną weryfikacją podpisywanej informacji. Jeżeli dany urząd certyfikacji zaświadcza
swoim podpisem, że znajdujący się w certyfikacie klucz publiczny należy do osoby A,
pracującej w firmie X, znajdującej się w państwie Y, to poprzedza ten akt upewnieniem
się, że umieszczane dane są prawdziwe.

Uzyskanie certyfikatu poświadczonego przez główny urząd certyfikacji może być
kosztowne, dlatego też w obrębie PKI powstały mniejsze jednostki, świadczące usługi
certyfikacji. Zaufanie do certyfikatów wydawanych przez te jednostki wynika z faktu
poświadczenia autentyczności tych jednostek przez główne urzędy certyfikacji.
Poświadczenie to ma postać podpisu zaświadczającego o prawdziwości danych takiej
jednostki i jej klucza publicznego, które jest dodawane do certyfikatu wydawanego
użytkownikowi końcowemu przez urząd pośredni. W efekcie, certyfikat wystawiany przez
pośredni urząd certyfikacji ma format rozszerzony w stosunku do formatu
przedstawionego na rysunku 1, a dodatkowym elementem jest poświadczenie
wiarygodności urzędu pośredniego przez urząd główny. Nic nie stoi na przeszkodzie, aby
powyższa procedura została powtórzona — otóż możliwe jest uzyskanie certyfikatu
w urzędzie pośrednim, który sam jest certyfikowany w urzędzie pośrednim, który z kolei
też jest certyfikowany przez inny urząd pośredni itd., i dopiero któraś z kolejnych
instytucji tego łańcucha ma wiarygodność poświadczaną przez główny urząd certyfikacji.
Jeżeli wiarygodność danych jest poświadczana według tak zbudowanego schematu,
certyfikat ma strukturę łańcuchową, a kolejnymi ogniwami tego łańcucha są następne
certyfikaty.

Infrastruktura klucza publicznego ma więc organizację hierarchiczną, przedstawioną na
rysunku 2, gdzie na przeciwnych krańcach piramidy znajdują się główne urzędy
certyfikacji i użytkownicy, zaś między nimi może występować dowolna ilość podrzędnych
urzędów certyfikacji.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Główny urząd certyfikacji (root CA)

Podrzędny urząd certyfikacji

Użytkownik

Podrzędny urząd certyfikacji

Rysunek 2. Struktura systemu PKI

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

2. Proces certyfikacji

Aby mieć pewność co do autentyczności klucza publicznego partnera korespondencji oraz
co do identyfikujących go danych, musimy skorzystać z certyfikatu jako jedynej
wiarygodnej formy upowszechniania informacji. Każda próba ustanowienia kanału
bezpiecznej komunikacji między dwiema osobami (A i B) w infrastrukturze PKI musi
rozpocząć się od wymiany certyfikatów (rys. 3). Jeżeli obydwie strony wejdą
w posiadanie certyfikatów partnera, wtedy korespondencja będzie wiarygodna i tajna
w obydwu kierunkach. W przypadku, gdy tylko jedna ze stron przekaże certyfikat
partnerowi, zabezpieczenie informacji będzie połowiczne, niemniej takie jednostronne
przekazywanie certyfikatu jest scenariuszem najczęściej stosowanym w praktyce.

Certyfikat

010011011011011
011100111000....

CAX

Ważny do ........

Oświadczam, że B to .....

Rysunek 3. Ustanowienie bezpiecznego połączenia — przesłanie klucza publicznego

umieszczonego w certyfikacie, sygnowanym przez urząd certyfikacji CAX

Każdy, kto chce stać się zaufanym podmiotem komunikacji, musi uzyskać certyfikat.
Procedura ubiegania się o certyfikat składa się z kilku etapów, przedstawionych na
rysunku 4. Pierwszą fazą procedury jest wygenerowanie przez użytkownika, który
chciałby stać się posiadaczem certyfikatu, pary kluczy asymetrycznego systemu
kryptograficznego (kluczy kryptosystemu RSA lub kryptosystemu DSA). Do generowania
par kluczy służy wiele dostępnych programów, często stanowiących integralne elementy
systemów operacyjnych (przykładowym darmowym programem, przeznaczonym dla
różnych platform systemowych i pozwalającym na realizację szeregu operacji
niezbędnych dla korzystania z PKI, takich jak tworzenie kluczy, tworzenie i weryfikacja
certyfikatów itp., jest program OpenSSL).

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Generacja pary kluczy

Utworzenie samopodpisanego

certyfikatu CSR

Sprawdzenie danych

Sporządzenie certyfikatu

i odesłanie go do użytkownika

Upowszechnianie

certyfikatu

Użytkownik

Centrum certyfikacji (CA)

Rysunek 4. Etapy procedury certyfikacji

Pierwszy z pary utworzonych kluczy — klucz prywatny — jest umieszczany w chronionym
obszarze pamięci systemu operacyjnego (zwykle w postaci zaszyfrowanej). Drugi z nich
— klucz publiczny — staje się przedmiotem certyfikacji i upowszechniania. Po utworzeniu
pary kluczy użytkownik generuje dokument o strukturze identycznej ze strukturą
docelowego certyfikatu. W dokumencie tym umieszcza swój klucz publiczny oraz swoje
dane, w takim brzmieniu, w jakim chce, aby występowały w ostatecznej wersji
przyznanego mu certyfikatu, a następnie podpisuje go swoim kluczem prywatnym.
Przygotowany w ten sposób dokument nazywany jest prośbą o certyfikację (określaną
często akronimem CSR, pochodzącym od terminu Certificate Signing Request).
Dokument ten wysyłany jest do centrum certyfikacji, kończąc w ten sposób fazę
czynności niezbędnych do wykonania przez stronę ubiegającą się o certyfikat.

Po otrzymaniu prośby o certyfikację, urząd certyfikacji rozpoczyna procedurę weryfikacji
otrzymanych danych. Stopień szczegółowości sprawdzania może być różny, ale zawsze
następuje osobiste upewnienie się przez pracownika urzędu, czy osoba lub instytucja
figurująca w prośbie o wydanie certyfikatu rzeczywiście o niego występuje (pozwala to na
wykluczenie możliwości podszycia się pod zgłaszającego). Po weryfikacji danych
podmiotu występującego o certyfikat, urząd certyfikacji bada poprawność wygenerowanej
przez niego pary kluczy. Jest to dokonywane przez sprawdzenie, czy podpis danych
zawartych w CSR, utworzony przez zgłaszającego prośbę przy użyciu swojego klucza
prywatnego, daje się poprawnie zweryfikować kluczem publicznym, zawartym w CSR.
Jeżeli tak, urząd przystępuje do ostatniego etapu procedury certyfikacji, który stanowi
odpowiednie ustalenie informacji o certyfikacie (daty ważności, numeru i przeznaczenia)
oraz podpisanie danych certyfikatu przy użyciu swojego klucza prywatnego. Wyznaczony
podpis oraz informacja o użytym algorytmie wyznaczania podpisu są ostatecznie
umieszczane w końcowej sekcji certyfikatu, i tak przygotowany dokument jest odsyłany
do użytkownika.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Po uzyskaniu certyfikatu użytkownik powinien zainstalować go we wszystkich aplikacjach,
które korzystają z protokołów bezpiecznej komunikacji, bazujących na weryfikacji
zaufania na bazie infrastruktury klucza publicznego. Wymiana klucza publicznego między
aplikacjami, które chcą się ze sobą komunikować w sposób bezpieczny jest zawsze
dokonywana przez wymianę i sprawdzenie certyfikatów, zawierających te klucze.

Programowe narzędzia do tworzenia certyfikatów

Jednym z kilku powszechnie dostępnych programów, pozwalających na tworzenie
wszelkich elementów niezbędnych do korzystania z systemu PKI, jest wspomniany
OpenSSL. Program ten umożliwia wykonanie przedstawionych wcześniej etapów
procedury uzyskiwania certyfikatu, realizowanych zarówno przez osobę ubiegającą się
o certyfikat, jak i dokonywanych przez urząd certyfikacji. OpenSSL jest programem
darmowym, dostępnym w wersjach na obydwie istniejące obecnie, główne platformy
systemowe (czyli Windows i Unix/Linux).

Operacje, których wykonanie jest niezbędne w celu ubiegania się o certyfikat, to
generacja pary kluczy kryptosystemu asymetrycznego i utworzenie prośby o wydanie
certyfikatu. W programie OpenSSL operacje te wykonywane są przy użyciu
następujących instrukcji:
  Generacja kluczy kryptosystemu RSA

Do tworzenia kluczy kryptosystemu RSA w programie OpenSSL służy instrukcja

genrsa. Przykładowa składnia instrukcji, powodującej generację kluczy o długości

1024 bitów, które po utworzeniu zostaną umieszczone w pliku o nazwie
MojeKluczeRSA.key, jest następująca:

genrsa -out MojeKluczeRSA.key -des3 1024

Plik z kluczami zostanie zaszyfrowany przy użyciu algorytmu szyfrowania 3DES
(w programie do zabezpieczenia klucza można użyć innych algorytmów szyfrowania).
Klucz szyfrowania, użyty w algorytmie, będzie utworzony na podstawie hasła, o które
program poprosi użytkownika. Użytkownik powinien zadbać o to, aby hasło użyte do
zabezpieczenia dostępu do klucza było dostatecznie mocne.

 Generacja kluczy algorytmu DSA

W celu generacji kluczy algorytmu DSA (a więc, kluczy służących do sporządzania
podpisów cyfrowych) w programie OpenSSL konieczne jest wykonanie kolejno dwóch

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

operacji. Pierwsza z nich realizowana jest przy użyciu instrukcji dsaparam i pozwala na
generację parametrów niezbędnych do utworzenia klucza. Przykładowa składnia
polecenia tworzącego parametry algorytmu DSA, zapamiętywane w pliku o nazwie
KluczDSAParam.pem, ma postać:

dsaparam -out KluczDSAParam.pem 1024

Utworzenie kluczy DSA następuje w drodze wykonania instrukcji gendsa, bazującej na
wyniku powyższej operacji. Przykładowa składnia polecenia tworzącego klucze DSA,
które zostaną zapamiętane w pliku KluczDSAPryw.key po uprzednim zaszyfrowaniu ich
szyfrem 3DES (wykorzystującym podane przez użytkownika hasło), ma postać:

gendsa -out KluczDSAPryw.key -des3 KluczDSAParam.pem

 Generacja prośby o wydanie certyfikatu (CSR)

Prośba o wydanie certyfikatu generowana jest na podstawie utworzonego wcześniej

przez użytkownika pliku z kluczami, w efekcie wykonania polecenia req. Składnia
instrukcji powodującej utworzenie prośby o wydanie certyfikatu, umieszczanej w pliku
MojaProsba.csr, jest następująca:

req -new -key MojeKluczeRSA.key -out MojaProsba.csr

Po wykonaniu polecenia, użytkownik będzie poproszony o podanie hasła, którym
zabezpieczony został plik z utworzonymi przez niego kluczami. Dodatkowo będzie on
musiał wpisać szereg informacji wymaganych przez format przygotowywanego
certyfikatu (imię, nazwisko itp.).

Plik, zawierający prośbę o utworzenie certyfikatu (MojaProsba.csr) stanowi dokument
gotowy do wysłania do urzędu certyfikacji. Jego utworzenie podsumowuje operacje
wykonywane przez osobę występującą o wydanie certyfikatu.

Program OpenSSL pozwala również na realizację operacji wykonywanych przez urzędy
certyfikacji (wydawanie certyfikatów, zarządzanie certyfikatami, odwoływanie
certyfikatów itp.). Czynności wykonywane przez urząd certyfikacji realizowane są przy

użyciu polecenia ca. Przykładowo, składnia polecenia powodującego wydanie certyfikatu
użytkownikowi, który skierował do urzędu odpowiednią prośbę o certyfikację, ma postać:

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

ca –cert CertyfikatCA.crt -keyfile KluczPrywCA.pem -in MojaProsba.csr -

out MojCertyfikat.crt

Utworzony certyfikat będzie posiadał strukturę określoną przez format X.509 i będzie
umieszczony w pliku MojCertyfikat.crt. Do jego podpisania program potrzebuje klucza
prywatnego centrum certyfikacji (znajdującego się w pliku KluczPrywCA.pem) oraz
certyfikatu urzędu certyfikacji (zawartego w pliku CertyfikatCA.crt), z którego pobierane
są dane o urzędzie certyfikacji.

Po uzyskaniu certyfikatu użytkownik powinien dokonać jego instalacji w stosowanej przez
siebie aplikacji (np. w przeglądarce internetowej) oraz umożliwić tej aplikacji dostęp do
wygenerowanego wcześniej klucza prywatnego. Od tej chwili aplikacja taka staje się
gotowa do realizacji zewnętrznych próśb o ustanowienie bezpiecznego połączenia,
bazującego na utworzonych przez użytkownika narzędziach kryptografii asymetrycznej.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

3. Weryfikacja certyfikatu

Weryfikacja certyfikatu jest procedurą sprawdzenia prawdziwości danych posiadacza
certyfikatu, autentyczności danych podmiotu poświadczającego certyfikat i ważności
certyfikatu. Sprawdzenie certyfikatu polega na upewnieniu się, czy podpis cyfrowy
certyfikatu pasuje do danych znajdujących się w certyfikacie. Jeżeli tak, mamy pewność,
że dane posiadacza i klucz, zawarte w certyfikacie, są prawdziwe, jak również, że
certyfikat został rzeczywiście podpisany przez urząd, który figuruje w certyfikacie jako
wystawca. Weryfikacja podpisu cyfrowego wymaga użycia klucza publicznego urzędu
certyfikacji (wystawca certyfikatu podpisuje dane certyfikatu swoim kluczem
prywatnym). Dlatego też, aby możliwe było sprawdzenie certyfikatu, klucz publiczny
wystawcy musi znajdować się w posiadaniu osoby sprawdzającej. Większość powszechnie
stosowanych aplikacji, pozwalających na tworzenie bezpiecznych połączeń, zawiera
w sobie klucze publiczne szeregu głównych urzędów certyfikacji (VeriSign, Entrust,
Thawte itd.). Klucze te umieszczane są w przeglądarkach przez ich producentów przed
dystrybucją aplikacji, w postaci samopodpisanych certyfikatów. Przykładowe zbiory
certyfikatów znajdujących się w powszechnie stosowanych przeglądarkach internetowych
(Internet Explorer, Netscape) zostały przedstawione na rysunku 5.

Rysunek 5. Okno programu Internet Explorer (a) i Netscape Navigator (b) z informacją

o zainstalowanych certyfikatach głównych urzędów certyfikacji

Certyfikat samopodpisany to certyfikat podpisany kluczem prywatnym jego właściciela,
dlatego też wydawałoby się, że wykorzystanie znajdującego się w nim klucza publicznego
do weryfikacji innych certyfikatów powinno odbywać się z dużą ostrożnością. Jednakże do

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

samopodpisanych certyfikatów głównych urzędów certyfikacji, umieszczanych
w powszechnie używanych aplikacjach (przeglądarkach, programach do tworzenia
bezpiecznych połączeń czy programach pocztowych), można mieć praktycznie pełne
zaufanie. Po pierwsze, o upewnienie się co do ich prawdziwości dba producent takiej
aplikacji, a niedopatrzenie tak fundamentalnego elementu bezpieczeństwa byłoby
praktycznie równoważne z wyeliminowaniem takiego producenta z rynku. Po drugie,
każdy może dodatkowo upewnić się, czy samopodpisany certyfikat instytucji X
rzeczywiście do niej należy. W tym celu można wykorzystać elektroniczny „odcisk palca”
dokumentu, który jest elementem każdego certyfikatu (rys. 6) i który może zostać
sprawdzony przez porównanie go z identyczną informacją, publikowaną w innych
źródłach (na przykład, instytucje rządowe corocznie wydają pisemne dokumenty
zawierające „odciski palca” głównych urzędów certyfikacji).

Rysunek 6. Szczegółowe informacje o wybranym, samopodpisanym certyfikacie,

uwierzytelniającym urząd certyfikacji (w dolnym oknie widoczny „odcisk palca” certyfikatu,

uzyskany algorytmem SHA-1)

Załóżmy, że użytkownik A, posiadający klucze publiczne różnych urzędów certyfikacji,
przeprowadza weryfikację certyfikatu osoby B (co zostało schematycznie pokazane na
rys. 7). Jeżeli certyfikat osoby B jest podpisany kluczem urzędu CAX (znanego aplikacji),
klucz ten zostaje pobrany przez aplikację z bazy („magazynu”) certyfikatów i za jego
pomocą sprawdzona zostaje prawdziwości podpisu cyfrowego certyfikatu.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

CA1

CAX

CAN

CAX

Sprawdzenie

Cert... B

Rysunek 7. Sprawdzenie certyfikatu partnera komunikacji

Niepomyślna weryfikacja certyfikatu oznacza fałszywość zawartych w nim danych, fakt
modyfikacji danych w dokumencie po dokonaniu podpisu lub podpisanie certyfikatu przez
inną instytucję niż wskazana na certyfikacie. Niezależnie od przyczyny niepowodzenia,
aplikacja powinna automatycznie zakończyć próbę nawiązania takiego połączenia,
informując użytkownika o zaistniałym problemie. W przypadku pomyślnej weryfikacji
certyfikatu, następuje wykonanie trzech dodatkowych czynności:
  sprawdzenie, czy certyfikat nie został unieważniony,
  sprawdzenie terminu ważności certyfikatu,
  sprawdzenie przeznaczenia certyfikatu.

Sprawdzenie, czy certyfikat nie został unieważniony jest operacją mającą na celu
wykrycie próby posłużenia się wykradzionym kluczem prywatnym posiadacza certyfikatu.
Jeżeli ktokolwiek stwierdza, że jego klucz prywatny mógł zostać ujawniony osobom
trzecim (w wyniku włamania do jego systemu komputerowego, niedbałości lub z innych
powodów), musi podjąć starania o natychmiastowe unieważnienie posiadanego przez
siebie certyfikatu. Włamywacz dysponujący ukradzionym kluczem prywatnym może
zacząć podszywać się pod jego właściciela i dokonywać anonimowo przestępstw
o najbardziej dotkliwych konsekwencjach materialnych (certyfikaty otwierają drogę dla
handlu elektronicznego). Unieważnienie certyfikatu oznacza wpisanie go na specjalną
„czarną listę”, nazywaną listą certyfikatów unieważnionych (CRL — ang. Certficate
Revocation List). Procedura sprawdzania ważności certyfikatów przypomina procedury
stosowane przy korzystaniu z kart kredytowych, gdzie również stosuje się listy
skradzionych kart, sprawdzane przed wykonaniem odpowiednich operacji finansowych.

Sprawdzenie, czy certyfikat potencjalnego partnera komunikacji nie znajduje się na liście
certyfikatów unieważnionych, jest istotnym elementem procedury weryfikacji i polega na
wystosowaniu przez naszą aplikację zapytania do serwera list CRL. W zapytaniu takim

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

prosimy o sprawdzenie, czy numer badanego przez nas certyfikatu nie odpowiada czasem
jakiemukolwiek z elementów listy. Jeżeli w odpowiedzi uzyskamy potwierdzenie istnienia
wpisu na liście, odpowiadającemu sprawdzanemu przez nas numerowi certyfikatu, proces
nawiązywania połączenia zostanie przez naszą aplikację przerwany, ponieważ
najprawdopodobniej mamy do czynienia z próbą oszustwa. Każda aplikacja pozwalająca
na ustanawianie bezpiecznej komunikacji musi mieć dostęp do serwerów CRL (czyli musi
znać odpowiednie nazwy serwerów). Za utrzymanie, uaktualnianie i odpowiednią ochronę
serwerów CRL odpowiedzialne są urzędy certyfikacji. Procedura sprawdzenia, czy
certyfikat nie został unieważniony, została schematycznie przedstawiona na rysunku 8.

Nr ?

NIE

TAK

CRL

Serwer

Certyfikat

Nr 00123

Rysunek 8. Sprawdzenie, czy certyfikat nie został unieważniony

W przypadku stwierdzenia, że certyfikat nie został unieważniony, kolejnym etapem
procedury weryfikacji jest sprawdzenie daty ważności. Jeżeli termin ważności, widniejący
na certyfikacie został przekroczony, dalszy przebieg procedury zależy od decyzji
użytkownika. Wygaśnięcie certyfikatu nie oznacza automatycznie utraty wiarygodności
zawartych w nim danych — zwykle oznacza to, że jego posiadacz nie wystąpił o jego
przedłużenie w celu uniknięcia związanych z tym opłat. Ostatnim elementem
weryfikowanym w certyfikacie jest jego przeznaczenie. Podobnie jak w przypadku utraty
daty ważności, użytkownik może z dystansem potraktować fakt użycia certyfikatu
niezgodnego z określonym dla niego przeznaczeniem (na przykład, certyfikat został
wystawiony w celu poświadczania poczty, a ktoś próbuje użyć go do nawiązania
połączenia SSH).

Jeżeli procedura weryfikacji certyfikatu zostaje pomyślnie zakończona, można — bez
obawy o oszustwo — skorzystać z dostarczonego w certyfikacie klucza publicznego,
w celu szyfrowania wysyłanych do naszego rozmówcy danych (rys. 9). Wiadomość
zaszyfrowana kluczem publicznym uwierzytelnionego rozmówcy będzie mogła być
odszyfrowana tylko przez niego i nikogo innego, dając podstawę do ustanowienia kanału

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

bezpiecznej komunikacji. Dodatkowo, pomyślnie zweryfikowany certyfikat może zostać
zapamiętany w lokalnej bazie certyfikatów po to, aby przy kolejnej próbie nawiązania
połączenia ze zweryfikowanym już wcześniej rozmówcą pominąć procedurę ponownego
pełnego sprawdzania i od razu wykorzystać posiadany klucz publiczny.

Cert... B

Rysunek 9. Rozpoczęcie bezpiecznej sesji po pomyślnej weryfikacji certyfikatu — zaszyfrowanie

wiadomości kluczem publicznym odbiorcy, pobranym z certyfikatu

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

4. Wydawanie kluczy kryptograficznych przez urząd certyfikacji

Scenariusz postępowania, w którym sami generujemy klucze kryptografii asymetrycznej,
przygotowujemy samopodpisany certyfikat i występujemy o certyfikację, nie jest
jedynym możliwym sposobem tworzenia systemu użytkowników PKI. Inny wariant to
wygenerowanie zestawu kluczy dla zbioru użytkowników przez centrum certyfikacji,
organizujące dla rozważanej grupy strukturę bezpiecznej komunikacji. W takim
przypadku klucze kryptograficznego systemu asymetrycznego, zarówno prywatne, jak
i publiczne, są tworzone w jednym miejscu (przez administratora grupy) i umieszczane
w postaci certyfikatu o specjalnym formacie p12, określonym w PKCS#12
(

http://www.rsasecurity.com/rsalabs/default.asp

). Certyfikat ten składa się z dwóch

części: w pierwszej znajduje się klucz prywatny użytkownika, zaś w drugiej — certyfikat
w formacie X.509, zawierający jego klucz publiczny i dane, podpisane kluczem
prywatnym administratora, który wydaje klucze (rys. 10). Certyfikaty p12 są sygnowane
kluczem administratora grupy po to, aby zapewnić wiarygodność zawartych w nich
danych, a następnie szyfrowane i wysyłane do odpowiednich użytkowników. Hasła,
pozwalające na deszyfrację przesyłki są dostarczane użytkownikom w inny, bezpieczny
sposób (na przykład przekazywane osobiście). Deszyfracja certyfikatu jest procedurą,
w której po podaniu hasła następuje wyodrębnienie klucza prywatnego i części
zawierającej klucz publiczny (tzn. zwykłego certyfikatu X.509). Klucz prywatny jest
zapamiętywany w chronionym obszarze, administrowanym przez aplikację stosowaną do
deszyfracji, natomiast certyfikat X.509 z kluczem publicznym użytkownika jest gotowy do
użytku i rozsyłania między potencjalnych partnerów komunikacji.

Administrator

grupy: AG

Publiczny C

Prywatny C

Dane C

Certyfikat dla C

(X.509)

Prywatny AG

Certyfikat dla C

(X.509)

Hasło

Certyfikat dla C

(p12)

Dane C

Rysunek 10. Centralna generacja kluczy

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Przedstawiony scenariusz postępowania jest stosowany przede wszystkim w przypadku,
gdy chcemy udzielić określonej przez nas grupie użytkowników dostępu do pewnej
świadczonej przez nas usługi, przy czym chcemy, aby dostęp ten był możliwy
z dowolnego miejsca w Internecie. Ponieważ klucze generowane są przez administratora
grupy, nie obowiązuje zasada pełnej odpowiedzialności użytkownika za dokumenty
sygnowane jego kluczem prywatnym, dlatego też zastosowanie utworzonego w ten
sposób klucza jest ograniczone właściwie wyłącznie do nawiązywania utajnionej
komunikacji z serwerem, udostępniającym grupie poufne zasoby.

Tworzenie systemu użytkowników PKI

W niniejszej części zostanie zaprezentowany sposób praktycznego wdrożenia omówionej
wcześniej procedury centralnego tworzenia i dystrybucji kluczy. Utworzenie grupy
użytkowników, którzy będą mogli komunikować się między sobą przy wykorzystaniu
mechanizmów bezpieczeństwa, bazujących na idei PKI, składa się z następujących
etapów:
 utworzenia urzędu certyfikacji przez administratora grupy; urząd ten będzie tworzyć

klucze i certyfikaty,

 instalacji przez wszystkich członków grupy certyfikatu nowo utworzonego urzędu

w używanych przez siebie aplikacjach,

 generacji w urzędzie certyfikacji kluczy kryptograficznych i certyfikatów dla

użytkowników,

  instalacji kluczy prywatnych i osobistych certyfikatów przez wszystkich członków grupy

Poszczególne etapy tej procedury mogą być zrealizowane przy użyciu wspomnianego
wcześniej programu OpenSSL oraz narzędzi oferowanych przez aplikacje, przeznaczone
do realizacji bezpiecznej komunikacji.

Utworzenie urzędu certyfikacji
Administrator ustanawianej grupy będzie tworzył klucze i certyfikaty dla jej członków,
a więc będzie pełnił rolę urzędu certyfikacji. Utworzenie urzędu certyfikacji (który będzie
dalej nazywany urzędem certyfikacji grupy lub urzędem GCA), to utworzenie narzędzi
kryptograficznych, koniecznych do realizacji tych zadań, a więc generacja kluczy
i wystawienie samopodpisanego certyfikatu.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Narzędziem do utworzenia zarówno kluczy kryptograficznych, jak i certyfikatów może być
wspomniany wcześniej program OpenSSL. Jednoczesna generacja kluczy
i samopodpisanego certyfikatu jest możliwa w drodze wykonania instrukcji:

req –newkey rsa:2048 –keyout KluczPrywCA.pem –x509 –out CertCA.crt

Wykonanie polecenia powoduje najpierw utworzenie kluczy RSA o długości 2048 bitów,
które zostaną zapisane w pliku KluczPrywCA.pem, chronionym przed dostępem osób
niepowołanych, wprowadzanym przez użytkownika hasłem. Następnie tworzony jest
certyfikat w formacie X.509, w którym umieszczany jest utworzony klucz publiczny oraz
dane identyfikujące urząd certyfikacji (GCA). Dane te wprowadzane są na prośby, kolejno
wystosowywane przez program (przykładowe dane wprowadzone podczas tworzenia
certyfikatu urzędu GCA to: nazwa urzędu — Koziołek Matołek, kraj lokalizacji urzędu
— PL, miasto — Pacanów oraz adres e-mail — koma@pac.net). Utworzony certyfikat
zostaje zapamiętany w pliku CertCA.crt, a następnie jest rozsyłany do wszystkich
członków tworzonej grupy.

Instalacja certyfikatu urzędu GCA w aplikacjach użytkowników
Ponieważ członkowie tworzonej grupy będą porozumiewali się przy użyciu certyfikatów
wydanych przez urząd GCA, aplikacje weryfikujące te certyfikaty muszą posiadać klucz
publiczny wystawcy. Dlatego też każdy z użytkowników musi dokonać instalacji
otrzymanego od administratora samopodpisanego certyfikatu GCA w używanych przez
siebie aplikacjach. Procedura instalacji certyfikatu w przeglądarce internetowej,
pracującej w środowisku Windows XP, jest następująca: po otwarciu okna zarządzania
certyfikatami, wciśnięcie przycisku programowego Importuj powoduje uruchomienie
kreatora instalacji certyfikatu. W pierwszym oknie kreatora użytkownik wskazuje plik
z certyfikatem, który ma być zainstalowany, czyli otrzymany od administratora grupy plik
CertCA.crt (rys. 11a). Ponieważ certyfikaty są grupowane do różnych kategorii (osobiste,
innych osób czy urzędów certyfikacji), program pyta o to, gdzie ma zostać zainstalowany
certyfikat (w którym „magazynie certyfikatów”). Najwygodniej pozostawić miejsce
instalacji do automatycznego uznania aplikacji, zaznaczając odpowiednią opcję okna
(rys. 11b). Następnie aplikacja informuje użytkownika o szczegółach certyfikatu, który
ma zostać dodany (dane urzędu GCA zostały wprowadzone podczas wykonywania

polecenia req, opisanego w poprzednim temacie i są pokazane na rys. 11c) i jeżeli
użytkownik wyraża zgodę na instalację, umieszcza nowy certyfikat w swoich zasobach
(rys. 11d).

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Rysunek 11. Procedura importu certyfikatu: a) prośba o wskazanie pliku źródłowego i b) miejsca

umieszczenia certyfikatu; c) komunikat o instalowanym certyfikacie oraz d) lista zainstalowanych

certyfikatów po wykonaniu operacji

Utworzenie kluczy kryptograficznych i certyfikatów dla użytkowników grupy
Po utworzeniu urzędu certyfikacji GCA, administrator grupy może przystąpić do tworzenia
kluczy kryptograficznych (publicznych i prywatnych) i certyfikatów przeznaczonych dla jej
członków. Tworzenie kluczy kryptograficznych i certyfikatów dla użytkowników U1, U2
itd. przy użyciu programu OpenSSL odbywa się w opisany wcześniej sposób, przez
wykonanie instrukcji:

req –newkey rsa:1024 –keyout KluczRSA_U1.pem –out U1Req.pem
req –newkey rsa:1024 –keyout KluczRSA_U2.pem –out U2Req.pem

...

Wygenerowane prośby o certyfikację (U1Req.pem, U2Req.pem) są następnie
podpisywane przez urząd certyfikacji:

ca –cert CertCA.crt -keyfile KPrywCA.pem -in U1Req.pem -out U1Cer.pem

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

ca –cert CertCA.crt -keyfile KPrywCA.pem -in U2Req.pem -out U2Cer.pem

...

Certyfikaty są sygnowane przez urząd kluczem prywatnym urzędu (KPrywCA.pem). Dane
umieszczane w certyfikacie pochodzą z dwóch źródeł: samopodpisanego certyfikatu
urzędu (CertCA.crt) oraz wygenerowanej wcześniej prośby o certyfikację.

Przedstawione do tego momentu operacje, a więc tworzenie kluczy kryptograficznych,
generacja prośby o certyfikację i podpisanie certyfikatu, prawie w niczym nie odbiegają
od procedury certyfikacji opisanej we wcześniejszej części. Zasadniczą innowacją jest
ostatni etap postępowania, w którym tworzone są dokumenty przeznaczone do
dystrybucji między użytkowników tworzonej grupy. Dokumenty, które otrzyma każdy
z użytkowników będą zawierać klucz prywatny i certyfikat z kluczem publicznym (zgodnie
z rys. 10). Polecenie programu OpenSSL, pozwalające na utworzenie takich dokumentów,
to instrukcja pkcs12, o następującej składni:

pkcs12 -export -in U1Cer.pem -inkey KluczRSA_U1.pem -out U1Cert.p12

Argumentami instrukcji są składniki tworzonego dokumentu: certyfikat z kluczem
publicznym, przeznaczonym dla użytkownika (U1Cer.pem) i jego klucz prywatny
(KluczRSA_U1.pem). Całość umieszczana jest w pliku U1Cert.p12 i chroniona hasłem,
przekazywanym użytkownikowi w bezpieczny sposób (np. osobiście).

Instalacja kluczy kryptograficznych przez użytkownika
Po otrzymaniu od administratora grupy certyfikatu

p12, każdy z użytkowników musi

przeprowadzić procedurę jego instalacji w systemie operacyjnym. Procedura instalacji
w przypadku środowiska Windows jest inicjowana automatycznie po uruchomieniu pliku
zawierającego certyfikat. Podczas instalacji kolejno pojawiać się będą okna kreatora
importu certyfikatu, zawierające prośby o wprowadzenie niezbędnych informacji.
Użytkownik powinien kolejno:
 wskazać położenie pliku zawierającego importowany certyfikat — ponieważ,

w omawianym przypadku, kreator jest uruchamiany w wyniku akcji użytkownika,
dotyczącej pliku zawierającego klucz, plik ten jest ustawiony domyślnie jako źródło
certyfikatu (rys. 12a);

 wprowadzić hasło, którym zabezpieczony jest dostęp do pliku — dane zawarte

w certyfikacie są chronione hasłem, przekazanym wcześniej użytkownikowi, które
powinno zostać wprowadzone do okna dialogowego, pokazanego na rysunku 12b.

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

Dodatkowo, użytkownik może zaznaczyć dwie inne opcje, dotyczące administrowania
jego kluczem prywatnym;

 wybrać magazyn certyfikatów, w którym zostanie umieszczony, pobrany

z przetwarzanego dokumentu

p12, certyfikat X.509 — podobnie jak poprzednio,

określenie odpowiedniego magazynu certyfikatów można pozostawić do decyzji
instalatora (rys. 12c)

Rysunek 12. Kreator importu certyfikatów: a) wskazanie pliku z instalowanymi kluczami,

b) autoryzacja użytkownika instalującego klucz, c) określenie miejsca instalacji certyfikatu,

d) posumowanie wykonanych czynności

Po zakończeniu instalacji, kreator wyświetla okno z informacją podsumowującą wykonaną
procedurę. W jej wyniku, w systemie operacyjnym zostaje umieszczony plik z kluczem
prywatnym użytkownika oraz certyfikat tego użytkownika, podpisany przez urząd GCA.
Informacje o nowych elementach systemu można uzyskać, przeglądając uaktualnioną
zawartość „magazynu certyfikatów”. Nowo zainstalowany certyfikat został automatycznie

Krzysztof Ślot Infrastruktura klucza publicznego (PKI)

umieszczony w sekcji Certyfikaty osobiste „magazynu certyfikatów” (rys. 13a), wraz
z informacją o instalacji w systemie klucza prywatnego użytkownika (rys 13b).

Rysunek 13. Informacje o nowo zainstalowanych składnikach: a) certyfikacie użytkownika

(użytkownik U1 to Sierotka Marysia, administratorem wydającym certyfikat, czyli urzędem GCA

jest Koziołek Matołek), b) kluczu prywatnym użytkownika (czyli Sierotki Marysi)

Document Outline