Wprowadzenie do PKI i SSL
Paweł Krawczyk
[e-mail]
8 lutego 2001
Spis treści
1 Wprowadzenie 2
2 Protokół SSL 2
2.1 SSL w modelu ISO/OSI . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Przeznaczenie SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 SSL jako protokół otwarty . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Rola PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5 Kryptografia w SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.6 Działanie protokołu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Infrastruktura klucza publicznego (PKI) 4
3.1 Hierarchia CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Weryfikacja tożsamości . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Zakres ochrony PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Implementacje 7
5 Terminologia 7
6 O autorze 8
1
1 Wprowadzenie
Celem niniejszego referatu jest przedstawienie protokołu SSL wraz leżącymi u jego
podstaw mechanizmami kryptograficznymi oraz praktycznych aspektów jego zastoso-
wania. Ma on w założeniu pozwolić Czytelnikowi na wykorzystanie zalet dostępnych
powszechnie otwartych implementacji SSL oraz pokazać, jak niskim kosztem można
zapewnić znaczny wzrost bezpieczeństwa podstawowych usług takich jak poczta elek-
troniczna.
Wymagana jest podstawowa znajomość tematyki sieci opartych o TCP/IP, konfi-
guracji usług pod systemami uniksowymi i innych zagadnień, typowych dla admini-
stracji sieciami komputerowymi.
2 Protokół SSL
Protokół SSL (Secure Sockets Layer) został w początkowej wersji opracowany przez
firmę Netscape1 i stał się wkrótce standardem, powszechnie stosowanym w Internecie.
Ostatnia, trzecia wersja protokołu (SSLv3) stała się podstawą do opracowania nieco
2
ulepszonego i firmowanego przez IETF protokołu TLS (Transport Layer Security).
2.1 SSL w modelu ISO/OSI
Mechanizmy zapewniające poufność oraz integralność przesyłanych danych są do-
stępne praktycznie dla każdej warstwy modelu sieci ISO/OSI. W odniesieniu do
TCP/IP warstwy te  wraz z dostępnymi zabezpieczeniami  są przedstawione
(w uproszczeniu) w poniższej tabeli:
Warstwa ISO/OSI Protokoły Zabezpieczenia
aplikacji POP3, HTTP PGP, S/MIME, SSL
transportowa TCP, UDP SSL
sieci IP IPSEC
fizyczna Ethernet, ISDN szyfratory sprzętowe
2.2 Przeznaczenie SSL
Podstawowymi zadaniem SSL jest zapewnienie bezpiecznego kanału dla protokołów
wyższych warstw. Kanał taki, dzięki zastosowaniu kryptografii, powinien być zupełnie
nieprzezroczysty dla osoby podsłuchującej łączność lub próbującej modyfikować jej
przebieg. SSL gwarantuje następujące funkcje:
1
Netscape Corporation, http://home.netscape.com/
2
Organizacja tworząca standardy techniczne Internetu, Internet Engineering Task Force,
http://www.ietf.org/
2
" Autentyczność stron, czyli pewność, że obie strony połączenia (klient i ser-
wer) są rzeczywiście tymi, za których się podają.
" Poufność transmisji, czyli ochronę przesyłanych danych przed podsłuchem
przez ich zaszyfrowanie.
" Integralność danych, czyli pewność, że przesłane dane nie zostały zmodyfi-
kowane po drodze, czy to w wyniku awarii czy złośliwej ingerencji.
2.3 SSL jako protokół otwarty
Jednym z podstawowych założeń SSL była otwartość i rozszerzalność protokołu, czyli
brak przywiązania do jednego, konkretnego algorytmu szyfrującego. Zamiast tego
protokół umożliwia stronom przedstawienie swoich propozycji obsługiwanych algo-
rytmów i wybranie wspólnego, najbardziej odpowiedniego dla obu stron.
Przykładowo, klient łączący się z serwerem po SSL może oznajmić mu, że może
użyć algorytmów szyfrujących DES, 3DES oraz RC4. Jeśli serwer stwierdzi, że z za-
proponowanej listy obsługuje wyłącznie RC4, to ten właśnie algorytm zostanie użyty
do zabezpieczenia transmisji.
2.4 Rola PKI
Zapewnienie autentyczności stron jest realizowane przez zbiór standardów określa-
3
nych jako infrastruktura klucza publicznego (PKI ). Jest to skomplikowany system,
pozwalający na hierarchiczne potwierdzanie tożsamości stron komunikacji (klientów
i serwerów), który omówimy poniżej.
Wykorzystanie PKI daje protokołowi SSL przewagę np. nad wykorzystującym
podobne szyfry protokołem SSH4 i czyni go odpornym na ataki polegające na pod-
szywaniu się pod zaufaną stronę połączenia, takie jak man in the middle. Należy
podkreślić, że nie jest to jednak własność zapewniana przez sam protokół, ale ra-
czej przez połączenie mechanizmów kryptograficznych z odpowiednimi procedurami
organizacyjnymi, takimi jak certyfikacja uczestników systemu.
2.5 Kryptografia w SSL
Jak wiele innych protokołów tego rodzaju, SSL wykorzystuje dwa podstawowe ro-
5
dzaje szyfrów  szyfry asymetryczne (z kluczem prywatnym i publicznym) oraz
6
symetryczne (z jednym kluczem szyfrująco deszyfrującym). Pierwsze z nich są
3
Public Key Infrastructure.
4
Secure Shell http://www.ssh.fi
5
Takie jak RSA i Diffie Hellman.
6
Takie jak DES, 3DES, IDEA, RC4, Blowfish.
3
wykorzystywane do uwierzytelnienia stron oraz bezpiecznej wymiany klucza syme-
trycznego, który z kolei służy do faktycznego szyfrowania strumienia danych.
Powody, dla których tak się robi są dwa: po pierwsze, algorytmy z kluczem pu-
blicznym są znacznie wolniejsze od szyfrów symetrycznych, przez co nie nadają się do
wydajnego kodowania danych przesyłanych w dużych strumieniach. Z drugiej jednak
strony zastosowanie tylko i wyłącznie szyfru symetrycznego wymagałoby wcześniej-
szej wymiany klucza za pomocą jakiegoś innego kanału. Połączenie dwóch rodzin
szyfrów rozwiązuje oba te problemy w sposób efektywny i elegancki.
2.6 Działanie protokołu
Typowa sesja SSL składa się z następujących kroków:
1. Nawiązanie przez klienta połączenia do serwera (po zwykłym TCP).
2. Wymiana informacji o obsługiwanych szyfrach, certyfikatów tożsamości i innych
danych.
3. Uzgodnienie wspólnego zbioru obsługiwanych algorytmów.
4. Potwierdzenie tożsamości serwera przez klienta na podstawie otrzymanych in-
formacji (opcjonalnie także w drugą stronę).
5. Wymiana kluczy sesyjnych (session keys), wygenerowanych w sposób losowy.
6. Rozpoczęcie transmisji całkowicie szyfrowanej wygenerowanymi wcześniej klu-
czami.
W punktach 2, 3 i 4 wykorzystywany jest szyfr asymetryczny, wybrany ze wspólnej
listy7. Po zakończeniu ostatniego (5) etapu kanał SSL staje się całkowicie przezroczy-
sty dla tunelowanego wewnątrz protokołu wyższej warstwy.
Do szyfrowania właściwych danych tunelowanych w SSL jest wykorzystywany
szyfr symetryczny, jeden z uzgodnionych podczas początkowej wymiany. Klucz szy-
frujący jest generowany losowo dla każdego połączenia.
3 Infrastruktura klucza publicznego (PKI)
Podstawą uwierzytelnienia w SSL są mechanizmy infrastruktury klucza publicznego
(PKI), oparte o kryptografię asymetryczną. W modelu tym każdy węzeł posiada swój
7
W praktyce jest to najczęściej algorytm RSA z kluczem o długości 512 lub 1024 bitów.
4
klucz prywatny, chroniony przed kradzieżą, oraz klucz publiczny, który jest wy-
syłany do klienta podczas nawiązywania połączenia. Z punktu widzenia klienta łą-
czącego się z takim systemem nie jest to jednak wystarczające dla stwierdzenia au-
tentyczności przedstawionego klucza publicznego  w przypadku ataku typu man
in the middle klucz ten mógłby być przecież podstawiony.
Jak się przed tym zabezpieczyć? W modelu PKI najważniejszą rolę spełnia tutaj
zaufana trzecia strona (trusted third party), czyli ktoś obdarzany zaufaniem przez
obie strony połączenia. W praktyce może to być instytucja rządowa, firma posiada-
jąca odpowiednią akredytację lub, w ramach jednej instytucji, wydzielona komórka
ogranizacyjna. W terminologii PKI organy te są określane wspólną nazwą urzędów
certyfikujących CA (Certifying Authority).
Rolą CA jest w przypadku SSL uprzednie stwierdzenie tożsamości serwera oraz
poświadczenie jej przez złożenie podpisu cyfrowego na kluczu publicznym zainte-
resowanego. Dowody przedstawiane przez tego ostatniego urzędowi zależą oczywiście
od kontekstu  w przypadku właściciela sklepu internetowego, oferującego SSL i
chcącego uzyskać certyfikat jednej z uznanych, światowych firm certyfikujących (Ve-
riSign8, Thawte9) będzie to dokument poświadczający istnienie danej firmy (wypis
z ewidencji gospodarczej), prawo do domeny sklepu (uzyskany od firmy rejestrującej
domeny, np. NASK10 lub Network Solutions11) itp. W przypadku CA działającego
w obrębie jednej firmy może to być zaświadczenie z działu kadr lub wręcz ustna
deklaracja przełożonego, w zależności od wielkości i polityki firmy.
3.1 Hierarchia CA
Jak widać, PKI jest sytemem w ogromnym stopniu skalowalnym, gdyż pracuje równie
dobrze w ramach jednej firmy, międzynarodowej korporacji oraz ogólnoświatowej sieci
certyfikacji publicznej, stosowanej obecnie w Internecie. Taka złożoność nie byłaby
możliwa gdyby PKI nie było systemem hierarchicznym  umożliwia ono bowiem
delegację części uprawnień certyfikacyjnych do podmiotów niższego szczebla.
Mówiąc obrazowo, urząd certyfikujący szczebla rządowogo może podpisać klucz
publiczny urzędu działającego w ramach określonej instutucji, dzięki czemu może ona
tworzyć certyfikaty dla własnych pracowników bez angażowania organu nadrzędnego.
Równocześnie, dzięki podpisowi złożonemu przez krajowego CA, certyfikaty wy-
generowane przez tę instutucję będą mogłby być weryfikowane tak samo skutecznie,
jakby były one wygenerowane przez urząd wyższego szczebla.
8
VeriSign, http://www.verisign.com/
9
Thawte, http://www.thawte.com/
10
NASK, http://www.nask.pl/
11
Network Solutions, http://www.networksolutions.com/
5
3.2 Weryfikacja tożsamości
Jak przebiega sprawdzenie tożsamości serwera legitymującego się certyfikatem? Przede
wszystkim, klient musi w tym celu posiadać klucz publiczny urzędu, który pod-
pisał dany certyfikat albo urzędu wyższego szczebla. Jest to podstawowe założenie
PKI i punkt, od którego zależy bezpieczeństwo całego systemu, jako że klucz CA
potwierdza tożsamość wszystkich kolejnych ogniw łańcucha certyfikacji.
Klucz ten musi być więc w bezpieczny sposób dostarczony do klienta. W przy-
padku przeglądarek internetowych takich jak Netscape Navigator lub MS Internet
Explorer największe firmy certyfikujące płacą producentom przeglądarek za umiesz-
czenie ich certyfikatów nadrzędnych w kolejnych wersjach programów. Dzięki temu ich
użytkownicy mogą w bezpieczny sposób weryfikować certyfikaty serwerów podpisane
przez te firmy.
Sama weryfikacja odbywa się w ten sposób, że przeglądarka klienta po otrzymaniu
od serwera jego certyfikatu sprawdza jaki urząd go podpisał. Następnie szuka w swojej
wewnętrznej bazie certyfikatu tego urzędu. Jeśli go nie znajdzie, może spróbować
poszukać go w bazie zewnętrznej  do tego celu wykorzystuje się powszechnie katalogi
LDAP.
Załóżmy, że przeglądarka uzyska w ten sposób poszukiwany certyfikat. Należy
jednak w tym momencie pamiętać, że certyfikat otrzymany z sieci nie jest godny za-
ufania  katalog mógł paść ofiarą włamania, a certyfikat może być fałszywy. Dlatego
program w tym momencie sprawdzi, kto z kolei podpisał uzyskany z bazy certyfikat
CA.
Jeśli nikt (czyli jest to ostatni w łańcuszku certyfikacji), to hierarchia podpisów
zostaje naruszona, otrzymany od serwera klucz publiczny nie może być uznany za
godny zaufania i program pyta o decyzję użytkownika.
Jeśli jednak certyfikat CA został podpisany przez urząd znany przeglądarce (po-
siada ona jego klucz publiczny wbudowany na stałe), to autentyczność klucza serwera
jest potwierdzona.
3.3 Zakres ochrony PKI
Autentyczność podpisu na kluczu publicznym nie jest jedyną cechą zapewnianą przez
SSL. Sprawdzane są także daty wystawienia oraz utraty ważności certyfikatu (mógł on
zostać wystawiony tylko na rok) oraz  opcjonalnie  czy nie był on anulowany przez
ogłoszenie na publicznej liście unieważnionych certyfikatów (Certificate Revocation
List).
Faktyczne wykorzystanie licznych mechanizmów zapewnianych przez PKI zależy
od implementacji oraz potrzeb użytkownika, określonych przez projektanta konkret-
nego wdrożenia.
6
4 Implementacje
PKI jest zbiorem standardów, tworzonych wspólnie przez producentów oprogramo-
wania oraz międzynarodowe instytucje normalizacyjne i publikowanych obecnie przez
ITU-T jako normy X.509. Dostępnych jest wiele implementacji obejmujących całość
lub wybrane fragmenty tych standardów  w chwili obecnej co najmniej kilkadziesiąt
firm z całego świata sprzedaje takie implementacje albo w postaci gotowych produk-
tów korzystających z PKI, albo bibliotek przeznaczonych dla programistów.
Najpopularniejszą implementacją dostępną z kodem z
ródłowym oraz liberalną li-
cencją jest OpenSSL12. Zawiera ona kompletny zestaw procedur X.509v3, protokołu
SSL oraz szeregeu algorytmów kryptograficznych w postaci bibliotek oraz aplikacji
narzędziowych. Jest ona przy tym wciąż intensywnie rozwijana
Biblioteka OpenSSL jest jedną z najczęściej wykorzystywanych przez inne pro-
gramy open source bibliotek kryptograficznych ogólnego przeznaczenia. Korzystają z
niej m.in. serwery Apache-SSL13, OpenSSH14 i inne. Biblioteka ta jest również sercem
programu Stunnel15, prezentowanego na konferencji Open Source Security.
5 Terminologia
" SSL  Secure Sockets Layer, protokół służący do budowania szyfrowanych i
uwierzytelnianych kanałów, działający pomiędzy protokołami warstwy trans-
portowej (TCP, UDP) i aplikacyjnej (POP3, HTTP).
" PKI  Public Key Infrastructure, zbiór standardów ustanawiających środki
techniczne do wykorzystania kryptografii z kluczem publicznym (asymetrycz-
nej) na potrzeby potwierdzania tożsamości, hierarchicznego składania podpisów
cyfrowych i wymiany kluczy w protokołach kryptograficznych. Standardy PKI
noszą różne nazwy, w zależności od autorów: i tak, dokumenty tworzone przez
firmę RSA Data Security16 są publikowane pod nazwą PKCS17, podczas gdy
publikacje ITU-T18 używają oznaczenia X.509.
" Man in the middle  atak polegający na przejmowaniu danych przesyła-
nych pomiędzy klientem a serwerem. Atakujący jest w tym wypadku ulokowany
pomiędzy stronami połączenia i działa jako pośrednik, udając tego drugiego
przed każdą ze stron. Przed atakiem tym nie da się zabezpieczyć wyłącznie
12
OpenSSL, http://www.openssl.org/
13
Apache SSL, http://www.modssl.org/
14
OpenSSH, http://ww.openssh.com/
15
Stunnel, http://www.stunnel.org/
16
RSA Data Security http://www.rsalabs.com/
17
Public Key Cryptography Standards
18
ITU Telecommunication Standardization Sector, http://info.itu.ch/ITU-T/
7
za pomocą technik kryptograficznych  konieczne jest wykorzystanie dodat-
kowego, zewnętrznego systemu ochrony potwierdzania tożsamości, takiego jak
PKI.
" certyfikat PKI  pakiet danych, zawierający klucz publiczny certyfikowanego
podmiotu (serwera, osoby), informacje na temat tego ostatniego (nazwa, adres).
Certyfikat zawiera także podpis cyfrowy urzędu certyfikującego poświadczający
prawdziwość danych oraz autentyczność klucza publicznego.
6 O autorze
Paweł Krawczyk  25 lat, mieszka w Krakowie, sieciami komputerowymi zajmuje
się od początku lat 90-tych. W tym czasie współpracował z wieloma firmami polskimi
i zagranicznymi jako administrator, programista i konsultant. Od kilku lat zajmuje się
głównie bezpieczeństwem sieci oraz kryptograficzną ochroną danych, na stałe pracuje
firmie ABA.
Adres Telefon Strona
Paweł Krawczyk [phone] http://ceti.pl/ kravietz/
ABA
ul. Żabiniec 19
31 215 Kraków
8
Bibliografia
[1] Netscape Corporation  Introduction to SSL ,
http://developer.netscape.com/docs/manuals/security/sslin/
[2] Netscape Corporation  The SSL Protocol version 3.0 Internet Draft ,
lhttp://home.netscape.com/eng/ssl3/
[3] IETF  The TLS Protocol Version 1.0 (RFC 2246),
http://www.ietf.org/rfc/rfc2246.txt
[4] IETF  Transport Layer Security IETF Working Group ,
http://www.ietf.org/html.charters/tls-charter.html
[5] Consensus Development Corporation  SSL Talk FAQ ,
http://www.faqs.org/faqs/computer-security/ssl-talk-faq/
[6] IETF  Public-Key Infrastructure (X.509) IETF Working Group ,
http://www.ietf.org/html.charters/pkix-charter.html
[7] RSA Data Security  RSA Laboratories Public Key Cryptography Standards ,
http://www.rsasecurity.com/rsalabs/pkcs/
[8] RSA Data Security  An Overview of the PKCS Standards ,
ftp://ftp.rsasecurity.com/pub/pkcs/ps/overview.ps.gz
[9] RSA Data Security  PKCS #1: RSA Cryptography Standard ,
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html
[10] E. Gerck and MCG  Overview of Certification Systems: X.509, CA, PGP and
SKIP , http://www.mcg.org.br/certover.pdf
9