Infrastruktura klucza publicznego – PKI

Infrastruktura klucza
Publicznego
Public Key Infrastructure (PKI)
Krzysztof Boryczko
Remigiusz Górecki
Bezpieczna komunikacja

Poufność (ang. Confidentiality)
Przesyłanie informacji w sposób tajny – tylko właściwy adresat
może je odczytać.

Autentyczność (ang. Authenticity)
Potwierdzenie tożsamości osoby wysyłającej dane – wiadomo kim
jest osoba wysyłająca informacje.

Integralność (ang. Integrity)
Dane pozostają niezmienione w czasie ich przesyłania.

Niezaprzeczalność (ang. Nonrepudiation)
Mamy pewność co do tożsamości osoby wysyłającej dane – nie
wyprze się ona przesłanych informacji.
Definicja i role PKI

Infrastruktura klucza publicznego – PKI (ang. Public Key
Infrastructure):
◦ Jest to system kryptograficzny umożliwiający bezpieczną
wymianę informacji pomiędzy jednostkami (podmiotami) biorącymi
udział w transakcji elektronicznej w oparciu o certyfikaty cyfrowe,
◦ Sprawdza tożsamość podmiotów i wydaje im (na określony czas)
odpowiednie certyfikaty cyfrowe potwierdzające ich wiarygodność,
◦ Zarządza certyfikatami cyfrowymi: wydaje, przechowuje,
dystrybuuje oraz unieważnia je (przechowuje listę unieważnionych
certyfikatów),
◦ Umożliwia szyfrowanie informacji w oparciu o klucze publiczne
podmiotów biorących udział w wymianie informacji.
Relacje zaufania
Każdy podmiot legitymuje się certyfikatem
zawierającym jego klucz publiczny.
 Konieczna jest pewność że dany klucz należy do
danego podmiotu.
 Przykładowo ktoś może się chcieć podszyć pod daną
firmę dając nam certyfikat należący rzekomo do niej.
 Sposoby weryfikacji przynależności certyfikatu:

◦ Osobiście,
◦ Sieć zaufania (ang. Web of trust) ,
◦ Infrastruktura klucza publicznego PKI.
Osobiste sprawdzanie klucza

Kontaktujemy się telefonicznie z przedstawicielem
danego podmiotu (przykładowo firmy), który osobiście
dyktuje nam np. odcisk klucza publicznego firmy
◦ Musimy mieć pewność, że po drugiej stronie jest faktycznie
osoba posiadająca odpowiednie uprawnienia,
◦ Obdarzamy więc zaufaniem rozmówcę, co może być ryzykowne,
◦ Rozmówca może podać nam przykładowo swój klucz, a nie firmy.

Udajemy się osobiście do siedziby firmy i sami
potwierdzamy autentyczność certyfikatu podmiotu
◦ Najbezpieczniejszy sposób – nie ma żadnych osób pośrednich,
którym musielibyśmy zaufać,
◦ Najmniej praktyczne – trudno udawać się osobiście do każdego
podmiotu (czas i koszty).
Zaufanie typu web of trust









Podobna idea jak osobistego sprawdzania.
Nie sprawdzamy osobiście wszystkich, lecz część.
Obdarzamy zaufaniem wybrany przez siebie podmiot,
wierząc że on weryfikuje innych.
Możemy wybrać dowolną ilość, dowolnych podmiotów,
których obdarzamy zaufaniem.
Przyjmujemy klucze podpisane przez zaufane podmioty.
Budowana jest sieć zaufania – dany podmiot weryfikuje
osobiście tych, którzy geograficznie są blisko niego.
Praktyczniejsze niż osobiste sprawdzanie wszystkich.
Nie mamy żadnych gwarancji prawnych, że wybrany
podmiot jest uczciwy – sami obdarzamy go zaufaniem.
Stosowane w PGP i podobnych (OpenPGP, GnuPG)
Zaufanie w PKI
Istnieją urzędy certyfikacji CA, które obdarzone są
zaufaniem przez wszystkie podmioty.
 CA są tak zwaną zaufaną trzecią stroną – TTP
(ang. Trusted Third Party).
 Poświadczają one autentyczność podmiotów w PKI.
 Użytkownicy nie wybierają podmiotu, któremu ufają
spośród użytkowników lecz obdarzają zaufaniem
odpowiednią instytucje.
 Najwyżej w hierarchii są główne CA mające odpowiednie
poświadczenia prawne.
 Kolejne CA są przez nie uwierzytelnione – sieć zaufania.
 Istnieją niepotwierdzone CA, których użytkownik sam
obdarza zaufaniem.

Zaufana trzecia strona – TTP


Instytucja rządowa – w Polsce Narodowe Centrum
Certyfikacji prowadzone przez Departament Obrony
Narodowego Banku Polskiego,
Firma posiadająca stosowną akredytację – w Polsce:
◦ Krajowa Izba Rozliczeniowa S.A. – „Szafir”,
◦ Polska Wytwórnia Papierów Wartościowych S.A. – „Sygillum”
◦ Unizeto Technologies S.A – „Certum”.

Wydzielona komórka organizacyjna w przedsiębiorstwie
administrująca wewnętrzną hierarchią urzędów
certyfikacji, które wysyłają certyfikaty odbiorcom
końcowym (komputerom, usługom sieciowym lub
osobom); nie koniecznie poświadczona przez inne CA.
Struktura PKI
W skład infrastruktury PKI wchodzą takie elementy jak
CA, RA oraz użytkownicy
 Urząd rejestracji – RA (Registration Authority)

Potwierdza tożsamość podmiotu ubiegającego się o certyfikat i
zezwala (bądź nie) na wydanie certyfikatu dla niego,

Urząd certyfikacji – CA (Certificate Authority)
Jest to organizacja wydająca certyfikat cyfrowy w oparciu o klucz
publiczny, potwierdzający tożsamość jego właściciela. Jest
przykładem „zaufanej trzeciej strony” – TTP (Trusted Third Party)

Użytkownicy
Są to zarówno instytucje, jak i osoby czy systemy świadczące
odpowiednie usługi (www, poczta, itp.) posiadające certyfikaty
cyfrowe oraz ich klienci.
Przypomnienie pojęć
związanych z szyfrowaniem
Szyfrowanie – procedura przekształcania informacji
nieszyfrowanej (jawnej) w informację zaszyfrowaną
(tajną) za pomocą odpowiedniego klucza.
 Deszyfrowanie – procedura przekształcania informacji
zaszyfrowanej w jawną z wykorzystaniem odpowiedniego
klucza.
 Klucz – ciąg znaków o określonej długości, który
umożliwia wykonywanie czynności kryptograficznych
takich jak szyfrowanie lub deszyfrowanie.
 Szyfrogram – zaszyfrowana informacja, która nie jest
możliwa do odczytania bez odpowiedniego klucza
deszyfrującego.

Szyfrowanie symetryczne
Ten sam klucz jest wykorzystywany do szyfrowania i
deszyfrowania informacji.
 Klucz jest zazwyczaj przypisywany do danego kanału
informacyjnego, a nie do posiadacza.
 Przykłady: DES, 3DES, AES, RC4, IDEA, Blowfish

Rodzaje szyfrowania symetrycznego

Szyfrowanie strumieniowe
◦ Odbywa się na poziomie poszczególnych bitów strumienia danych
◦ Dane są na bieżąco szyfrowane przy użyciu tajnego klucza (np.
operacja XOR, który może ulegać zmianie w czasie szyfrowania
◦ Najbardziej znany algorytm to RC4.

Szyfrowanie blokowe
◦ Dane są dzielone na bloki o określonej długości i bloki te są
szyfrowane.
◦ Tryb ECB (ang. Electronic CodeBook) – bloki szyfrowane są
niezależnie tym samym kluczem. Te same bloki danych dadzą ten
sam szyfrogram, a więc łatwiejszy atak na duże dane.
◦ Tryb CBC (ang. Cipher Block Chaining) – blok jawny jest przed
szyfrowaniem sumowany (operacja XOR) z szyfrogramem bloku
poprzedniego. Pierwszy blok z wektorem inicjalizacyjnym.
Szyfrowanie asymetryczne



Klucz publiczny (jawny) adresata wiadomości – dostępny
dla wszystkich, upubliczniony, użyty do szyfrowania.
Klucz prywatny (tajny) unikatowy, znany jedynie
właścicielowi, chroniony – tylko on może odkodować.
Przykłady: RSA, DSA, ElGamal
Podpis cyfrowy
Analogiczny mechanizm jak w przypadku szyfrowania
asymetrycznego, lecz odwrotne zastosowanie kluczy.
 Stosowane te same algorytmy, jak np. RSA czy DSA.
 Klucz prywatny (podmiotu, który podpisuje)
wykorzystywany jest przy składaniu podpisu cyfrowego.
 Odbiorca zna klucz publiczny nadawcy i weryfikuje nim
podpis pod wiadomością.

Funkcja skrótu (hash
(hash))

Podstawowe cechy funkcji skrótu:
◦ Skrót daje się utworzyć łatwo, natomiast odwrócenie operacji ma
być niemożliwe (funkcja jednokierunkowa),
◦ Wynik generowany jest na podstawie całego wejścia,
◦ Zmiana jednego bajtu (znaku) – całkiem inny wynik,
◦ Niezależnie od długości wejścia wynik ma tę samą długość dla
danego algorytmu.

Przykłady algorytmów:
DES, MD2, MD4, MD5, SHA1, SHA256, SHA512, itp.
Cechy szyfrowania symetrycznego

Zalety:
◦ Bardzo szybkie (stosowane do dużych ilości danych),
◦ Zapewnia poufność informacji,
◦ Może (ale nie musi) zapewniać integralności, np. w trybie CBC
odszyfrowanie całości gwarantuje, że dane nie zostały zmienione.

Wady:
◦ Jest jeden wspólny klucz, który ma być znany tylko stronom
wymieniającym informacje. Problem z przekazaniem klucza w
sposób bezpieczny.
◦ Nie zapewnia autentyczności i niezaprzeczalności.
Cechy szyfrowania asymetrycznego

Zalety:
◦ Zapewnia poufność informacji,
◦ Nie ma problemu z przekazywaniem kluczy, gdyż prywatny
posiada jedynie jego właściciel,
◦ Wykorzystanie podpisu cyfrowego zapewnia integralność,
autentyczność i niezaprzeczalność.

Wady:
◦ Stosunkowo wolne (RSA wolniejsze około 1000 razy od DES) –
nie nadaje się do szyfrowania większej ilości danych czy strumieni
informacji jak w np. w VPN.
Realizacja bezpiecznej komunikacji

Poufność – dane są szyfrowane i tylko podmiot znający
odpowiedni klucz może je odszyfrować – dla osób
trzecich są niemożliwe do odczytania
◦ Kryptografia symetryczna – obie strony posiadają ten sam klucz i
tylko one mogą odczytywać przesyłane informacje,
◦ Kryptografia asymetryczna – informacje szyfrowane są kluczem
publicznym adresata i tylko on może je odczytać, ponieważ
posiada odpowiedni klucz prywatny.

Autentyczność – podpis cyfrowy pod wiadomością
potwierdza tożsamość jej autora.
◦ Podpis może złożyć tylko ten kto ma klucz prywatny,
◦ Autor udostępnia klucz publiczny, więc wszyscy którzy go
otrzymają mogą weryfikować podpis.
Bezpieczna komunikacja c.d.

Integralność – podpis cyfrowy zapewnia o niezmienności
danych
◦ Podpis cyfrowy wykonywany jest pod całą wiadomością,
◦ Zmiana danych zmienia podpis cyfrowy,
◦ Najczęściej podpisuje się skrót wiadomości.

Niezaprzeczalność – podpis cyfrowy określa jednoznacznie
autora wiadomości – nie wyprze się on jej
◦ Nie ma dwóch takich samych kluczy prywatnych,
◦ Klucz prywatny potrzebny do podpisu znany jest tylko jego
właścicielowi,
Jak sprawdzić czy klucz prywatny należy do właściwej osoby?
Klucz prywatny jest niczym dokument tożsamości – przyznawany jest
jedynie właściwej osobie (po potwierdzeniu jej tożsamości). Wydaje
go uprawniony organ – TTP.
Certyfikat klucza publicznego

Dokument elektroniczny potwierdzający tożsamość
podmiotu legitymującego się kluczem publicznym.

Jest podpisany przez podmiot, któremu ufamy – TTP.

Potwierdza autentyczność klucza publicznego.

Zawiera takie informacje jak:
◦ Informacje o podmiocie – jego nazwa, umiejscowienie geograf. Itp.
◦ Informacje o wystawcy, który go podpisał,
◦ Czas ważności certyfikatu,
◦ Klucz publiczny podmiotu,
◦ Podpis elektroniczny wystawcy.

Przykłady certyfikatów: X.509, PGP, SPKI/SDSI
Standard X.509

X.509 – standard ITU-T (International Telecommunication
Union w Genewie) wywodzący się ze standardu X.500

Opisuje certyfikaty i sposób zarządzania nimi w PKI

Umożliwiający stworzenie hierarchicznej struktury
powiązanych z sobą CA - w odróżnieniu od Web of Trust.

Określa schemat i normy dla:
◦ Certyfikatów kluczy publicznych,
◦ Odwołań certyfikatów – listy CRL,
◦ Certyfikatów atrybutu uprawnień.

X.509v3 opisany w RFC 5280 i PN-ISO/IEC 9594-8 (2006)

Protokoły i standardy wykorzystujące X.509: smartcard,
SSH, IPsec, TLS/SSL – HTTPS, IMAPS, LDAPS, itp.
Standard X.509 a X.500

Standard X.509 wchodzi w skład grupy dotyczącej usług
katalogowych i wywodzących się z protokołu X.500.

W certyfikatach X.509 pojawia się nazwa podmiotu i
wystawcy – obie jako nazwa wyróżniona w formacie X.500

Struktura nazwy wyróżnionej (ang. Distinguished Name)
◦ C (Country Name) – nazwa kraju,
◦ ST (State or Province Name) – nazwa stanu, prowincji,
województwa, itp.
◦ L (Locality Name) – nazwa miejscowości,
◦ O (Organization Name) – nazwa organizacji,
◦ OU (Organization Unit Name) – nazwa jednostki, działu w
ogranizacji,
◦ CN (Common Name) – nazwa identyfikująca podmiot.
RSA PKCS – standardy PKI
PKCS (ang. Public-Key Cryptography Standards) –
to standardy kryptograficzne publikowane przez
RSA The Security Division of EMC.
 PKCS to normy przemysłowe dotyczące kryptografii
z kluczem publicznym, czyli szyfrowania
asymetrycznego. Najczęściej wykorzystywane to:

◦ PKCS #1 – definiuje matematyczne własności oraz format kluczy
publicznych i prywatnych dla algorytmu RSA. Opisuje również
podstawowe algorytmy wykorzystywane do szyfrowania i
tworzenia podpisów z wykorzystaniem RSA.
◦ PKCS #7 – standard kryptograficznego kodowania wiadomości.
Opisuje dane, które podlegają operacjom kryptograficznym.
Wykorzystywany w przypadku przesyłania żądania odnowienia
certyfikatu lub podczas jego eksportowania – RFC 2315
RSA PKCS – standardy PKI c.d.
◦ PKCS #8 – standard opisujący format zapisu klucza
prywatnego – RFC 5208.
◦ PKCS #10 – standard kodowania wniosku o certyfikat
wysyłanego do CA – RFC 2986.
◦ PKCS #11 – standard kodowania interfejsu tzw. żetonu
kryptograficznego. Używany w celu realizacji modelu Single
sign-on w Infrastrukturze klucza publicznego. Taki format mają
certyfikaty cyfrowe umieszczane na kartach inteligentnych.
◦ PKCS #12 – standard kodowania informacji osobistych.
Opisuje formaty zapisu danych kryptograficznych.
Wykorzystywany przy przesyłaniu pary kluczy (prywatny,
publiczny), które są dodatkowo chronione hasłem. Stosowany
jest do przechowywania certyfikatów osób.
Certyfikat X.509 klucza
publicznego

Certyfikat X.509 v3 klucza publicznego składa się z
następujących części:
◦ Certyfikat – zawiera standardowe pola opisujące certyfikat oraz
opcjonalną część związaną z rozszerzeniami – od wersji 3 X.509
◦ Algorytm sygnatury certyfikatu – najczęściej SHA1 z RSA
◦ Wartość sygnatury certyfikatu – podpis certyfikatu złożony przez
CA w formacie DER w kodowaniu ASN.1
Certyfikat X.509 klucza
publicznego c.d.

Standardowe i obowiązkowe pola certyfikatu X.509 klucza
publicznego zawiera pola – od wersji 2:
◦ Wersja – numer standardu X.509; aktualnie 3 – w polu wartość 2
◦ Numer seryjny – unikalny w obrębie CA numer certyfikatu
◦ Algorytm sygnatury certyfikatu – najczęściej SHA1 z RSA
◦ Wystawca – nazwa wyróżniona CA, które podpisało certyfikat
◦ Ważność
 Nieważny przed – data od kiedy certyfikat jest ważny
 Nieważny po – data po której certyfikat traci ważność
◦ Podmiot – nazwa wyróżniona podmiotu, którego jest to certyfikat
◦ Informacje o kluczu publicznym
 Algorytm klucza publicznego – najczęściej RSA
 Klucz publiczny – zawartość klucza publicznego; z reguły już 2048 bitów
Certyfikat X.509 klucza
publicznego c.d.

Od wersji 3 X.509 certyfikat może zawierać rozszerzenia.

Umożliwiają definiowanie dodatkowych atrybutów
związanych z użytkownikami i zarządzaniem certyfikatami.

Rozszerzenie posiada swe ID, wartość i pole logiczne
określające czy jest ono krytyczne.

Gdy jest ono krytyczne musi mieć wartość i być znane.

Przykłady rozszerzeń:
◦ Podstawowe ograniczenia certyfikatu – wartością może być
przykładowo „Nie jest organem certyfikacji” – krytyczne,
◦ Punkty dystrybucji CRL – zawiera URI miejsca z listą odwołań
certyfikatów – niekrytyczne.
Postać DN w X.509

Nazwa wyróżniona – DN musi jednoznacznie (w obrębie
CA) identyfikować podmiot.

DN składa się z części opisującej położenie podmiotu
(geograficzne i logistyczne w obrębie organizacji) oraz z
nawy potocznej – CN.

W praktyce nazwa potoczna – CN podmiotu powinna
spełniać następujące reguły:
◦ W przypadku certyfikatu dla serwera usługi (poczta, www, itp.) jest
jego adresem w postaci FQDN – np. poczta.wszib.edu.pl,
◦ W przypadku certyfikatu dla CA jest adresem domenowym
organizacji – np. wszib.edu.pl,
◦ W przypadku certyfikatu wystawianego osobie jej imię i nazwisko.
Przykład certyfikatu X.509 - suszi
Przykład certyfikatu X.509 - tekst
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:4a:7a:dc:f5:c3:61:7e:1a:d6:da:96:cc:69:7c:30
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting
cc, OU=Certification Services Division, CN=Thawte Premium Server
CA/
CA/[email protected]
Validity
Not Before: Mar 24 00:00:00 2010 GMT
Not After : Mar 24 23:59:59 2011 GMT
Subject: C=PL, ST=Małopolska, L=Kraków, O=Wyższa Szkoła
Zarządzania i Bankowości, OU=suszi, CN=suszi.wszib.edu.pl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:e7:16:8b:8c:79:1e:db:f0:9b:65:98:4e:13: ……
Przykład certyfikatu X.509 – c.d.
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.thawte.com/ThawteServerPremiumCA.crl
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access:
OCSP - URI:http://ocsp.thawte.com
Signature Algorithm: sha1WithRSAEncryption
03:b6:a6:25:84:4b:28:36:72:27:43:20:58:19:2f:9c:a8:fa: …...
---------BEGIN
CERTIFICATE----MIIEFzCCA4CgAwIBAgIQAkp63PXDYX4a1tqWzGl8MDAN ……
---------END
CERTIFICATE-----
Certyfikat X.509 CA

Certyfikat CA od certyfikatu klucza publicznego różni się
jedynie wartością odpowiedniego pola rozszerzeń:
X509v3 Basic Constraints:
CA:TRUE
Self signed certyfikat CA

Z reguły certyfikaty CA są podpisywane przez inne CA
będące wyżej w hierarchii poświadczające autentyczność.

Najwyższe w hierarchii (root certificates) nie mają przez
kogo być potwierdzone i podpisane są przez ich twórców
(ang. self signed certificates).

Jeśli certyfikat CA nie jest poświadczony przez zaufane
CA, to musi być obdarzony zaufaniem przez podmiot
korzystający z certyfikatów przez niego podpisanych.

Każdy może utworzyć własne CA i podpisać go samemu –
przykładowo CA w firmie – ufają mu wszyscy pracownicy.

Certyfikat self signed ma zarówno w polu określającym
podmiot jak i wystawcę tę samą nazwę wyróżniającą DN.
Ścieżka certyfikatów w X.509

Gdy certyfikat klucza publicznego podpisany jest przez
CA, to przy prawidłowej konfiguracji powinna być
widoczna hierarchia – dane uwierzytelniającego CA

W przypadku certyfikatu CA self signed nie będzie nic
ponad nim samym w hierarchii:

Dla certyfikatu klucza publicznego podpisanego przez CA
uwierzytelnione przez inne CA ścieżka certyfikacji:
Praktyczna realizacja PKI

Najczęściej spotykane wykorzystanie PKI – bezpieczne
www (protokół HTTPS) i poczta (POP3S, IMAPS).

Proces potwierdzania tożsamości podczas bezpiecznego
połączenia np. www czy poczta:
◦ Łączymy się z witryną, która przedstawia się certyfikatem klucza
publicznego,
◦ Oprogramowanie klienckie (przeglądarka, program pocztowy)
sprawdza podpis certyfikatu serwera:
 Jeśli podpisany jest przez jedno z głównych CA, których listę klient ma
wbudowaną, to potwierdza to jego tożsamość,
 Jeśli podpisany jest przez nieznane CA, to użytkownik otrzyma stosowne
ostrzeżenie i będzie musiał sam potwierdzić zaufanie do niego.
◦ Po uznaniu autentyczności serwera zostaje nawiązana sesja.
Ostrzeżenie – nieznane CA

Nawiązanie połączenia z serwerem przedstawiającym się
certyfikatem podpisanym przez nieznane CA

Użytkownik musi sam podjąć decyzję czy zaakceptować
certyfikat tymczasowo lub na stałe czy go odrzucić.
Niezgodność DN z FQDN

Różnicy w adresie z polem DN certyfikatu – niewłaściwa
witryna:
Import certyfikatu CA

Możliwe jest zaimportowanie do systemu Windows czy
Linux certyfikatu danego CA i obdarzenie go zaufaniem.

Certyfikaty kluczy publicznych podpisane przez obdarzone
zaufaniem CA będą miały potwierdzaną autentyczność.

Zaimportowanie certyfikatu CA na potrzeby programu
firefox:
Listy odwołań certyfikatów

Lista odwołanych certyfikatów – CRL (ang. Certificate
Revocation List) przechowywana jest w CA.

Znajdują się w niej numery seryjne certyfikatów.

Podmioty korzystające z PKI pobierają cyklicznie CRL i
sprawdzają nie tylko ważność czasową certyfikatów, lecz
także ich obecność na liście.

Przykładowe przyczyny odwołania certyfikatu w czasie
jego ważności:
◦ Zmiana nazwy podmiotu – konieczność zmiany pola DN,
◦ Ujawnienie klucza prywatnego podmiotu,
◦ Odejście pracownika z firmy legitymującego się certyfikatem,
◦ Niemożność wykorzystania klucza prywatnego użytkownika –
zgubienie tokenu, zapomnienie hasła do klucza, itp.
Certyfikaty atrybutu uprawnień

Certyfikaty atrybutu uprawnień AC (ang. Attribute
Certificate) opisane są w RFC 3281.

Wydawane są przez AA (ang. Attribute Authority).

Zawierają atrybuty danego podmiotu określające jego
uprawnienia – spełniają funkcję autoryzacji.

Wydawane najczęściej na podstawie uprzedniego
uwierzytelnienia podmiotu – sprawdzenia jego certyfikatu
klucza publicznego.

Podmiot może posiadać wiele certyfikatów AC nadających
mu różne uprawnienia.
Sposób uzyskania certyfikatu
1.
Użytkownik za pomocą odpowiedniego oprogramowania
generuje, dla siebie lub usługi, żądanie certyfikatu.
2.
Tworzony jest plik ze zgłoszeniem oraz klucz prywatny.
3.
Plik zgłoszenia, zawierający klucz publiczny, wysyłany
jest do urzędu certyfikacji – CA.
4.
Urząd rejestracji – RA weryfikuje tożsamość
zgłaszającego się podmiotu i po jej potwierdzeniu
zezwala CA na wydanie certyfikatu klucza publicznego.
5.
CA przyjmuje zgłoszenie i podpisuje je swoim kluczem
prywatnym tworząc certyfikat.
6.
Użytkownik otrzymuje podpisany przez CA certyfikat.
7.
Może już udostępniać otrzymany certyfikat.
Utworzenie self signed CA

Utworzenie CA za pomocą openSSL:
◦ Przygotowanie pustego pliku na bazę,
◦ Przygotowanie pliku na numery seryjne – na początek wartość 01
◦ Wygenerowanie certyfikatu – plik ca.crt oraz klucza prywatnego
– plik ca.key przykładowym poleceniem:
[franio@dns1 ~]$ openssl req -new -x509 -days 3650 -out ca.crt \
> -keyout ca.key

Po podaniu hasła zabezpieczającego klucz prywatny
wygenerowany zostanie klucz prywatny i certyfikat CA.

Stworzony został certyfikat podpisany przez samego
siebie – self signed CA. Wartości pól Issuer oraz Subject
są takie same.
Postać wygenerowanego CA

Wypisanie zawartości utworzonego certyfikatu CA
[franio@dns1 ~]$ openssl x509 -in ca.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ee:14:78:2c:90:85:9e:d2
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o.,
OU=IT
OU=IT,
CN=krakow.wszib.edu.pl
CN=krakow.wszib.edu.pl/[email protected]
Validity
Not Before: Apr 10 12:59:27 2010 GMT
Not After : Apr 7 12:59:27 2020 GMT
Subject: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o.,
OU=IT
OU=IT,
CN=krakow.wszib.edu.pl
CN=krakow.wszib.edu.pl/[email protected]
Subject Public Key Info: …..
Wygenerowanie zgłoszenia

Utworzenie za pomocą openSSL zgłoszenia – plik serv.req
i klucza prywatnego – serv.key
[franio@dns1 ~]$ openssl req -new -out serv.req -keyout serv.key

Wypisanie zawartości zgłoszenia
[franio@dns1 ~]$ openssl req -in serv.req -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=PL, ST=Malopolska, L=Krakow, O=Fimrma Frania sp.
z.o.o OU=IT-www, CN=secure.krakow.wszib.edu.pl/emailAddress=
z.o.o.,
[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c9:ec:0c:fc:3d:9d:01:51:27:52:29:6a:05:55: ……
Podpisanie zgłoszenia

Podpisanie zgłoszenia (utworzenie certyfikatu):
[franio@dns1 ~]$ openssl ca -cert ca.crt -keyfile ca.key -in serv.req \
> -out serv.crt -days 1825
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Apr 10 13:57:59 2010 GMT
Not After : Apr 9 13:57:59 2015 GMT
Subject:
countryName
= PL
stateOrProvinceName
= Malopolska
organizationName
= Firma Frania z.o.o.
organizationalUnitName
= IT-www
commonName
= secure.krakow.wszib.edu.pl
emailAddress
= [email protected]
…..
Podpisanie zgłoszenia c.d.
……
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
CA:58:4D:C7:DD:DF:6A:AC:68:DC:12:99:03:07:F9:3A:1F:13:A8:2F
X509v3 Authority Key Identifier:
keyid:CA:7F:2A:99:71:D5:E8:BF:AE:34:37:04:A5:C5:B6:51:04:53:7D:93
Certificate is to be certified until Apr 9 13:57:59 2015 GMT (1825 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Utworzony certyfikat
[franio@dns1 ~]$ openssl x509 -in serv.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o.,
OU=IT CN=krakow.wszib.edu.pl/emailAddress=
OU=IT,
[email protected]
Validity
Not Before: Apr 10 14:02:30 2010 GMT
Not After : Apr 9 14:02:30 2015 GMT
Subject: C=PL, ST=Malopolska, O=Firma Frania z.o.o., OU=IT-www,
CN=secure.krakow.wszib.edu.pl
CN=secure.krakow.wszib.edu.pl/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:a6:5f:6f:8d:fa:52:7d:19:e6:e1:28:d5:d8:a2: ……
Cechy certyfikatu

Ważność certyfikatu została ustalona przez CA podczas
podpisywania zgłoszenia i wpisana do certyfikatu.

W polu Subject znalazła się nazwa wyróżniona podmiotu
pobrana ze zgłoszenia.

W polu Issuer jest nazwa wyróżniająca podpisującego CA.

Certyfikat otrzymuje kolejny numer seryjny.

Numery seryjne i przyporządkowane im certyfikaty
przechowywane są w bazie CA – jeden certyfikat, to jedna
linia:
V
150409140230Z
01
unknown
/C=PL/ST=Malopolska/O=Firma Frania z.o.o./OU=ITwww
www/CN=secure.krakow.wszib.edu.pl/[email protected].
[email protected].
edu.pl
Bezpieczne przesyłanie danych
protokołów warstwy aplikacji
Protokół SSL/TLS
Krzysztof Boryczko
Remigiusz Górecki
Protokół SSL/TLS
Protokół TLS (ang. Transport Layer Security) jest
rozwinięciem protokołu SSL (ang. Secure Socket Layer).
 Ma za zadanie zapewnić poufność i integralność
przesyłanych danych.
 Wykorzystuje certyfikaty X.509 i PKI co umożliwia
potwierdzenie autentyczności serwera jak i klienta.
 Jest protokołem warstwy transportowej i prezentacji –
umożliwia enkapsulację i szyfrowanie protokołów warstwy
aplikacji; takich jak: HTTP, POP3, IMAP, SMTP, NNTP, itp.
 Protokoły wykorzystujące TLS z reguły posiadają
przydzielony oddzielny port i otrzymują nazwę z literą „s”
na końcu – HTTPS, POP3S, itp.
 Wykorzystywany jest również przez OpenVPN i SSL VPN

Historia protokołu SSL/TLS
1994 r. – Netscape opracowuje SSL v1 – wersja
wewnętrzna, niedostępna publicznie.
 1995 r. – SSL v2 pierwsza dostępna wersja protokołu.
 1996 r. – SSL v3 poprawiona wersja 2, gdyż zawierała ona
błędy związane z bezpieczeństwem.
 1999 r. – TLS v1.0 uaktualnienie SSL i uczynienie go
bardziej bezpiecznym. Zmiany na tyle duże, iż jest to nowa
wersja.
 2006 r. – TLS v1.1 dodane zabezpieczenie przed pewnymi
atakami na szyfry blokowe CBC.
 2008 r. – TLS v1.2 kilka istotnych zmian dotyczących
algorytmów szyfrowania.

TLS – zasada działania
Protokół klient / serwer.
 Jest to protokół połączeniowy.
 Protokół TLS składa się z dwóch warstw:

◦ TLS Record Protocol – umiejscowiony w warstwie transportowej –
ma za zadanie przesyłanie danych w sposób zapewniający
poufność i integralność.
Wykorzystane jest tu szyfrowanie symetryczne – np. 3DES.
◦ TLS Handshake Protocol – umiejscowiony ponad warstwą
transportową (w warstwie prezentacji) – jego zadaniem jest
wynegocjowanie parametrów połączenia, potwierdzenie tożsamości
serwera i klienta (jeśli wymagane) oraz ustalenie klucza sesji.
Wykorzystane jest tu szyfrowanie asymetryczne – głównie RSA.
TLS Record Protocol

TLS Record Protocol zapewnia bezpieczne połączenie
posiadające następujące cechy:
◦ Prywatność – przesyłane dane są szyfrowane w sposób
symetryczny (RC4, DES, 3DES, itp) z wykorzystaniem unikalnego
klucza. Klucz jest generowany dla danej sesji w czasie fazy
negocjacji – prookół TLS Handshake Protocol,
◦ Autentyczność – dane zawierają MAC (ang. Message
Authentication Code) co potwierdza ich autentyczności. Jest to
swego rodzaju podpis pod danymi wykorzystujący odpowiedni
klucz. Integralność jest zapewniona przez wykorzystanie funkcji
skrótu takich jak MD5 czy SHA.
TLS Handshake Protocol
TLS Handshake Protocol zapewnia przede wszystkim
nawiązanie sesji i wynegocjowanie jej parametrów.
 Wpierw następuje przedstawienie się podmiotów i
ustalenie wstępnych parametrów:

1. Klient wysyła wiadomość „Client hello” a w niej listę
obsługiwanych algorytmów szyfrowania, ID sesji oraz pewną
liczbę losową służącą później do ustalenia klucza sesji.
2. Serwer odpowiada wiadomością „Server hello”, w której wysyła
analogiczne informacje jak klient w swym powitaniu.
3. Serwer przedstawia swą tożsamość wysyłając swój certyfikat
klucza publicznego w formacie X.509. Może też zażądać
potwierdzenia tożsamości klienta. Na koniec wysyła wiadomość
„Server hello done”.
4. Punkt opcjonalny – klient wysyła swój certyfikat klucza
publicznego jeśli tego zażądał serwer.
TLS Handshake Protocol c.d.

Następnie jest ustalenie klucza sesji do szyfrowania
transmisji:
1. Klient wysyła wiadomość „Key exchange” , a w niej
wygenerowany losowo 48-bitowy (w przypadku RSA) premaster
key zaszyfrowany kluczem publicznym serwera.
2. Serwer otrzymawszy wiadomość odszyfrowuje ją swoim kluczem
prywatnym i generuje klucz sesji – do otrzymanego klucza dodaje
jako sól otrzymaną uprzednio losową liczbę od klienta oraz
wygenerowaną wcześniej przez siebie losową liczbę.
3. Klient posiadając wygenerowaną przez serwer liczbę generuje w
analogiczny sposób jak serwer klucz sesji.
TLS Handshake Protocol c.d.

Końcowa faza negocjacji to przełączenie się do warstwy
protokołu TLS Record Protocol umożliwiającej bezpieczne
wysyłanie danych:
1. Klient wysyła wiadomość „Change cipher spec” , która informuje
serwer, że klient jest gotów do szyfrowania danych za pomocą
klucza sesji i wynegocjowanego wcześniej algorytmu. Klient
przełącza się do warstwy protokołu TLS Record Protocol.
2. Klient wysyła wiadomość „Client finished”, która jest pierwszą
zaszyfrowaną wiadomością. Zawarte są w niej: klucz sesji,
wynegocjowane algorytmy itp.
3. Serwer otrzymawszy pierwszą wiadomość od klienta przełącza
się do warstwy protokołu TLS Record Protocol.
4. Otrzymawszy wiadomość nr 2 weryfikuje ją i odsyła analogiczną
„Server finished” do klienta.
5. Obie strony gotowe są do szyfrowanej transmisji danych.
Użycie protokołu SSL/TLS do
zabezpieczenia HTTP
Konfiguracja serwera www z SSL/TLS
Krzysztof Boryczko
Remigiusz Górecki
Instalacja Apache z SSL – RH
Instalacja serwera www Apache w dystrybucjach z rodziny
Red Hat – pakiet httpd.
 Wykorzystanie protokołu SSL/TLS przez serwer Apache
– instalacja pakietu mod_ssl.
 Główny katalog konfiguracyjny serwera www to /etc/httpd.
Znajdują się w nim katalogi:

◦ conf – katalog z plikami konfiguracyjnymi serwera Apache –
znajduje się w nim główny plik konfiguryjny serwera httpd.conf,
◦ conf.d – katalog z plikami konfiguracyjnymi rozszerzeń serwera
– znajduje się w nim między innymi plik ssl.conf, dotyczący
konfiguracji protokłu SSL/TLS.
◦ logs – katalog z dziennikami (logami) serwera,
◦ modules – katalog z modułami roszerzeń serwrera httpd,
◦ run – katalog z plikiem httpd.pid zawierającym PID procesu httpd.
Konfiguracja serwera Apache



Plik konfiguracyjny serwera – /etc/httpd/conf/httpd.conf.
W pliku znajdują się definicje atrybutów w postaci
nazwa_atrybutu wartość_atrybutu.
Plik zawiera bardzo dużą liczbę atrybutów; najważniejsze:
◦ User – nazwa użytkownika w kontekście którego będzie
uruchomiony serwer httpd (domyślnie – apache),
◦ ServerName – adres FQDN serwera (ewentualnie adres IP),
◦ ServerAdmin – adres e-mail administratora serwera,
◦ DocumentRoot – główny katalog strony www serwra,
◦ Listen – adres i numer portu na jakim nasłuchuje serwer,
◦ AccessFileName – nazwa pliku z dalszymi ustawieniami
konfiguracyjnymi serwera – domyślnie .htaccess
◦ LogLevel – poziom szczegółowości zapisywania informacji (logów)
– domyślnie warn.
Konfiguracja Apache c.d.
Plik zawiera również definicje sekcji takich jak IfModule,
Directory, Files, Proxy czy VirtualHost.
 Sekcja IfModule zawiera ustawienia dotyczące danego
modułu; przykładowo umożliwienie użytkownikom
wystawiania ich własnych stron w katalogu public_html:

<IfModule mod_userdir.c>
UserDir public_html
</
</IfModule>
Strona taka będzie widoczna pod adresem
http://adres.serwera/~nazwa_uzytkownika
 Wyłączenie takiej możliwości – ustawienie disabled jako
wartości atrybutu UserDir

Apache – Sekcja Directory
Sekcja Directory umożliwia zdefiniowanie własności i
parametrów dostępu związanych z danym katalogiem.
 Standardowe ustawienie głównego katalogu ze stroną:

<Directory ”/var/www/html”>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</
</Directory>

Ustawienie to oznacza:
◦ Zwrócenie indeksu (listy) plików z katalogu, gdy nie ma w nim pliku
strony, podążanie za dowiązaniami symbolicznymi,
◦ Zabronienie nadpisywania atrybutów wartościami z .htaccess
◦ Pozwolenie wszystkim na dostęp do zawartości tego katalogu.
Apache – hosty wirtualne
W przypadku gdy serwer www ma obsługiwać więcej niż
jeden adres FQDN stosuje się hosty wirtualne.
 Konfiguracja hosta wirtualnego może zawierać prawie
wszystkie ustawienia jakie definiowane są dla serwera.
 Stosuje się aktualnie definicje hostów oparte o ich nazwy
FQDN, a nie jak dawniej o adresy IP.
 Przykład włączenia obsługi hostów wirtualnych i definicja
przykładowego hosta www.krakow.wszib.edu.pl

NameVirtualHost *:80
<
<VirtualHost
*:80>
ServerName www.krakow.wszib.edu.pl
ServerAdmin [email protected]
ErrorLog logs/krakow.log
DocumentRoot /var/www/krakow
</
</Directory>
Konfiguracja SSL w Apache


W celu udostępnienia serwera www za pośrednictwem
protokołu HTTPS konieczna jest instalacja i konfiguracja
modułu mod_ssl.
Należy przygotować również następujące certyfikaty w
formacie X.509:
◦ Certyfikat klucza publicznego serwera podpisany przez
odpowiednie CA,
◦ Certyfikat klucza publicznego CA, które podpisało certyfikat serwera
– powinien zostać udostępniony przez CA,
◦ Plik z kluczem prywatnym serwera http – musi zostać umieszczony
w takim miejscu i z takimi prawami, aby dostęp do niego miał tylko
serwer Apache.
Konfiguracja SSL w Apache c.d.
Konfiguracja modułu mod_ssl znajduje się standardowo w
pliku /etc/httpd/conf.d/ssl.conf
 Składnia jest analogiczna jak konfiguracyjnego serwera.
 Najważniejsze atrybuty:

◦ Listen – numer portu na którym nasłuchuje serwer na szyfrowane
połączenia za pomocą protokołu HTTPS (standardowo 443)
◦ SSLCertificateFile – ścieżka do certyfikatu serwera,
◦ SSLCertificateKeyFile – ścieżka do pliku z kluczem prywatnym
serwera – odpowiadającemu kluczowi publicznemu z certyfikatu,
◦ SSLCAAertificateFile – ścieżka do certyfikatu CA – dzięki temu we
własnościach certyfikatu widzianych w przeglądarce będzie
widoczny certyfikat CA, które go podpisało,
◦ SSLVerifyClient – umożliwia wymuszenie weryfikacji klienta
– będzie musiał wylegitymować się odpowiednim certyfikatem.