01.10.2019 Strona 1 z 9 Infrastruktura Klucza Publicznego W laboratorium zostanie wykorzystane środowisko OpenSSL. Jest to zestaw narzędzi kryptograficznych, pozwalających na wykorzystywanie m.in. popularnych algorytmów kryptografii symetrycznej i asymetrycznej, funkcji skrótów i certyfikatów. Środowisko składa się z modułów, odpowiedzialnych za obsługę poszczególnych technologii. W zadaniu zostaną wykorzystane głównie moduły genrsa (do generowania kluczy RSA), rsa (do zarządzania kluczami) oraz req (do składania wniosków o podpisanie certyfikatu, tzw. CSR – Certificate Signing Request). Użytkowanie odbywa się w trybie interaktywnym (po wpisaniu polecenia openssl w terminalu) lub skryptowym: openssl MODUŁ PARAMETRY_MODUŁU W zadaniu wykorzystamy możliwość tworzenia infrastruktury klucza publicznego (PKI – Public Key Infrastructure). Utworzona zostanie najprostsza możliwa architektura PKI – główny urząd certyfikacji (Root CA) oraz jeden podległy mu urząd podpisujący (Signing CA): Rys.1. Architektura PKI z zadania (źródło tego i następnych obrazków: pki-tutorial.readthedocs.io). Należy mieć świadomość, że w rzeczywistym stosowaniu PKI architektura jest zazwyczaj dwuwarstwowa z wydzielonymi Intermediate CA, osobnymi dla usług różnych typów lub trójwarstwowa z dodatkowym podziałem zależnym od funkcji certyfikatów w danej usłudze (np. osobne CA do wystawiania certyfikatów dla użytkowników w sieci oraz osobne dla usług w tej samej sieci):
9
Embed
Infrastruktura Klucza Publicznegohome.agh.edu.pl/~dsuder/prymus/20191126_3-pki-infrastructure.pdf · (Root CA) oraz jeden podległy mu urząd podpisujący (Signing CA): Rys.1. Architektura
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
01.10.2019
Strona 1 z 9
Infrastruktura Klucza Publicznego
W laboratorium zostanie wykorzystane środowisko OpenSSL. Jest to zestaw narzędzi
kryptograficznych, pozwalających na wykorzystywanie m.in. popularnych algorytmów kryptografii
symetrycznej i asymetrycznej, funkcji skrótów i certyfikatów. Środowisko składa się z modułów,
odpowiedzialnych za obsługę poszczególnych technologii. W zadaniu zostaną wykorzystane głównie
moduły genrsa (do generowania kluczy RSA), rsa (do zarządzania kluczami) oraz req (do składania
wniosków o podpisanie certyfikatu, tzw. CSR – Certificate Signing Request).
Użytkowanie odbywa się w trybie interaktywnym (po wpisaniu polecenia openssl w terminalu) lub
skryptowym: openssl MODUŁ PARAMETRY_MODUŁU
W zadaniu wykorzystamy możliwość tworzenia infrastruktury klucza publicznego (PKI – Public Key
Infrastructure). Utworzona zostanie najprostsza możliwa architektura PKI – główny urząd certyfikacji
(Root CA) oraz jeden podległy mu urząd podpisujący (Signing CA):
Rys.1. Architektura PKI z zadania (źródło tego i następnych obrazków: pki-tutorial.readthedocs.io).
Należy mieć świadomość, że w rzeczywistym stosowaniu PKI architektura jest zazwyczaj
dwuwarstwowa z wydzielonymi Intermediate CA, osobnymi dla usług różnych typów lub
trójwarstwowa z dodatkowym podziałem zależnym od funkcji certyfikatów w danej usłudze (np.
osobne CA do wystawiania certyfikatów dla użytkowników w sieci oraz osobne dla usług w tej samej
sieci):
01.10.2019
Strona 2 z 9
Rys. 2. Typowa dwuwarstwowa architektura PKI.
Rys. 3. Typowa trójwarstwowa architektura PKI.
01.10.2019
Strona 3 z 9
Formaty zapisu certyfikatów:
DER - Distinguished Encoding Rules – binarny plik, często wykorzystywany w systemach Windows
(domyślny format eksportu kluczy i certyfikatów w Windows)
PEM - Privacy Enhanced Mail – certyfikat lub klucz, pierwotnie w formacie DER, zakodowany
w Base64, popularny w systemach Linux i większości oprogramowania (Apache mod_ssl, stunnel itd.)
P12 – PKCS #12 – format przechowywania pary kluczy (publicznego i prywatnego) w stanie
zaszyfrowanym, zabezpieczonych hasłem. Rozwinięty przez Microsoft i tam najczęściej spotykany,
opisany w RFC 7292.
Często spotykane są także rozszerzenia plików:
.key – klucz prywatny
.pub – klucz publiczny
.crt – certyfikat, często wykorzystywane rozszerzenie w Windows jako synonim do .pem
Instrukcja do ćwiczenia:
Główny urząd certyfikacji (Root CA) jest źródłem zaufania. Inne urządzenia w sieci ufają posiadaczom
certyfikatów podpisanych przez Root CA bezpośrednio (raczej rzadko spotykane rozwiązanie) lub
pośrednio, poprzez pośrednie urzędy certyfikacji (Intermediate CA), których zadaniem jest
wystawianie certyfikatów końcowym użytkownikom lub usługom.
Klucze prywatne powinny być dobrze chronione. Skompromitowanie klucza prywatnego prowadzi do
równoczesnego skompromitowania dokumentów podpisanych z jego pomocą – nie da się określić,
czy podpisy zostały wystawione przez prawowitego właściciela klucza. Szczególnie dobrze powinny
być chronione klucze urzędów certyfikacji. Dlatego też Root CA wykorzystuje się tylko do
podpisywania kluczy urzędów pośrednich – sam klucz Root CA przechowywany powinien być
w bezpiecznym środowisku, jak moduł HSM lub odizolowane od sieci urządzenie, wykorzystywane
tylko jako przestrzeń dla CA.
W przypadku skompromitowania CA skompromitowane zostają również wszystkie certyfikaty przez
niego wystawione, także pośrednio (nie jest problemem utworzyć pośrednie CA, korzystając ze
skradzionego klucza).
1. Utworzenie Root CA
Należy rozpocząć od utworzenia miejsca (katalogu) przechowywania plików składających się na Root
CA. Wykorzystany zostanie w tym celu katalog /root/ca:
# mkdir /root/ca
W stworzonym katalogu musi zostać utworzona struktura urzędu. Podkatalogi służą do
przechowywania wydanych certyfikatów (certs), nowych certyfikatów (newcerts), przechowywania
informacji o unieważnionych certyfikatach (crl) oraz klucza prywatnego CA (private). Podane nazwy
są przykładowe, jednak muszą zostać umieszczone w pliku konfiguracyjnym OpenSSL. Plik index.txt
jest wykorzystywany jako baza danych o podpisanych certyfikatach, a serial jest numerem
porządkowym ostatnio wydanego certyfikatu.
01.10.2019
Strona 4 z 9
# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
Następnym krokiem jest stworzenie pliku konfiguracyjnego OpenSSL dla urzędu certyfikacji.
Przykładowy plik dostępny jest pod adresem https://jamielinux.com/docs/openssl-certificate-
authority/appendix/root-configuration-file.html (bezpośredni link do pliku:
https://jamielinux.com/docs/openssl-certificate-authority/_downloads/root-config.txt lub skrócony:
http://urwij.net/1804/) i zostanie on przez nas użyty w dalszej części instrukcji. Nazwę pliku należy
zmienić na openssl.cnf lub w dalszej części instrukcji odpowiednio wykorzystywać aktualną nazwę.
Obowiązkowa sekcja [ ca ] zawiera wskazanie na stosowaną sekcję konfiguracji (może być ich więcej).
W sekcji [ default_ca ] odpowiedzialnej za konfigurację urzędu certyfikacji, wskazywana jest polityka
wystawiania certyfikatów. Określa ona, między innymi, jakie atrybuty muszą być w nich zawarte
i jakie wartości są dozwolone. W przypadku urzędu Root CA, przyjętą w przykładzie polityką jest
policy_strict, zostanie ona wykorzystana tylko dla certyfikatów wystawianych przez Root CA, a więc
tylko certyfikatów urzędów pośrednich. Certyfikaty końcowe (dla usług i użytkowników) wystawiane
będą z użyciem polityki policy_loose.
Za obsługę wniosków o podpisanie kluczy odpowiada sekcja [ req ] i wskazywane przez nią następne
sekcje. Dodatkowe atrybuty zawarte w certyfikatach, opisywane standardem X.509v3, obsługuje
sekcja [ v3_ca ].
Pozostałe sekcje omówione zostaną później.
Następnym krokiem jest utworzenie pary kluczy Root CA. Klucz musi być przechowywany
w bezpiecznym miejscu i mieć możliwie dużą długość – klucz prywatny Root CA wykorzystywany jest
rzadko i niska wydajność związana z długością klucza nie jest problemem. Dużo ważniejsze jest, by
klucz nie został skompromitowany.
Plik z kluczem szyfrowany jest z wykorzystaniem algorytmu symetrycznego, pozwalającego na
przechowywanie go w ukrytej formie, zabezpieczonej podanym hasłem. Hasła, ani klucza