LPI Security Essentials (Moduł 022.1) – Hash Vs Szyfrowanie

Zanim zaczniesz

Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.

Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.

Co, kiedy i po co + skrót PKI

Kryptografia to fundament bezpieczeństwa informacji w IT. Jednym z jej kluczowych elementów są funkcje skrótu (hash) oraz szyfrowanie – często mylone ze sobą przez początkujących. W niniejszym artykule wyjaśniamy, czym różni się nieodwracalna funkcja skrótu od odwracalnego szyfrowania, kiedy warto użyć każdej z tych metod i dlaczego są one potrzebne. Ponadto przedstawimy Perfect Forward Secrecy (PFS) i mechanizmy wymiany kluczy (np. ECDH), a także zwięźle omówimy Infrastrukturę Klucza Publicznego (PKI) – w tym urzędy certyfikacji (CA), łańcuch zaufania, certyfikaty X.509 (CSR, SAN) oraz mechanizmy unieważniania certyfikatów (CRL, OCSP). Całość wzbogacimy praktycznymi przykładami poleceń CLI (OpenSSL, GnuPG itp.) i zaleceniami wdrożeniowymi.

Funkcje skrótu (hash) – adekwatności i zastosowania

Czym jest funkcja skrótu? Funkcja skrótu to algorytm kryptograficzny, który z danych wejściowych o dowolnej długości tworzy ciąg o stałej długości, zwany skrótem (ang. hash lub digest). choćby minimalna zmiana w danych wejściowych powoduje drastyczną zmianę wygenerowanego skrótu, dzięki czemu funkcja skrótu jest bardzo czuła na modyfikacje. Ta cecha zapewnia integralność danych – jeżeli choć jeden bit wejściowy ulegnie zmianie, wygenerowany hash będzie zupełnie inny, co pozwala łatwo wykryć nieautoryzowane modyfikacje pliku czy wiadomości. istotną adekwatnością funkcji skrótu jest jej jednokierunkowość – na podstawie samego hashu praktycznie nie da się odtworzyć oryginalnych danych wejściowych. Innymi słowy, funkcja skrótu nie umożliwia odwrócenia procesu (brak klucza do “odszyfrowania” skrótu), co odróżnia ją od algorytmów szyfrujących.

Zastosowania funkcji skrótu: Dzięki opisanym adekwatnościom, funkcje skrótu znajdują szerokie zastosowanie w bezpieczeństwie informacji. Przykładowe scenariusze użycia to:

• Weryfikacja integralności plików: Dystrybutorzy systemu często publikują w repozytoriach sumy kontrolne (np. SHA-256) swoich plików instalacyjnych. Użytkownik po pobraniu pliku może obliczyć jego hash i porównać z oficjalnym – zgodność potwierdza, iż plik nie został zmodyfikowany podczas transferu. Przykładowo, obrazy instalacyjne Linuksa są zwykle udostępniane z dołączonymi sumami SHA-256, które można sprawdzić narzędziem sha256sum: $ sha256sum NazwaPliku.iso Wynik w postaci 64-znakowego ciągu szesnastkowego (256 bitów) porównujemy z wartością podaną przez wydawcę. jeżeli są identyczne, mamy pewność, iż plik jest oryginalny i nieuszkodzony.
• Podpisy cyfrowe: Funkcje skrótu są kluczowym elementem podpisu elektronicznego. Zamiast podpisywać całą wiadomość kluczem prywatnym (co byłoby nieefektywne dla dużych danych), nadawca tworzy skrót wiadomości i to właśnie ten krótki digest szyfruje swoim kluczem prywatnym, tworząc podpis cyfrowy. Odbiorca, korzystając z publicznego klucza nadawcy, odszyfrowuje podpis (uzyskując oryginalny hash), a następnie sam oblicza hash odebranej wiadomości. jeżeli oba hashe się zgadzają, oznacza to, iż treść nie została zmieniona po drodze oraz iż podpis pochodzi od posiadacza odpowiedniego klucza prywatnego (autentyczność nadawcy została potwierdzona). Takie mechanizmy są wykorzystywane m.in. w szyfrowanej poczcie email (PGP/GPG) oraz przy dystrybucji oprogramowania, aby zapewnić integralność i autentyczność danych.
• Przechowywanie haseł: Zamiast trzymać hasła użytkowników w bazie w postaci jawnej (co byłoby skrajnie niebezpieczne), systemy zapisują jedynie ich wartości skrótu. Gdy użytkownik się loguje, podane hasło jest haszowane i porównywane ze skrótem zapisanym w bazie – jeżeli się zgadzają, hasło jest poprawne i dostęp zostaje przyznany. Dzięki temu choćby wyciek bazy nie ujawnia haseł wprost. Co więcej, aby utrudnić ataki słownikowe i z użyciem tęczowych tablic (precompute’owanych hashy popularnych haseł), stosuje się technikę soli – do hasła przed hashowaniem dodawana jest losowa wartość (salt). Powoduje to, iż jednakowe hasła użytkowników będą miały różne skróty, co znacząco zwiększa bezpieczeństwo przechowywania haseł.

Przykładowe algorytmy hashujące: Wśród funkcji skrótu standardem bezpieczeństwa są rodziny SHA-2 (np. SHA-256, SHA-512) oraz SHA-3. SHA-256 generuje 256-bitowy skrót i jest powszechnie wykorzystywany w kryptografii – od protokołów komunikacyjnych, przez kryptowaluty (np. blockchain Bitcoina opiera się na SHA-256), po sumy kontrolne plików. SHA-3 to nowszy standard przyjęty przez NIST, oparty na innej konstrukcji (algorytm Keccak), również oferujący różne długości skrótu (np. 256-bitowy SHA3-256).

Dla zobrazowania działania funkcji skrótu, weźmy prosty tekst „HelloWorld” i obliczmy jego skrót SHA-256. Uzyskany hash (przedstawiony szesnastkowo) to:

a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b53d83a38ac8f0287

Jak widać, choćby tak krótki tekst daje pozornie losowy, długi ciąg znaków. jeżeli zmienimy choćby jedną literę, wynikowy hash będzie zupełnie inny.

Warto wspomnieć, iż starsze algorytmy hashujące, takie jak MD5 czy SHA-1, wyszły z użycia w kontekście bezpieczeństwa. Zostały w nich odkryte poważne luki kolizyjne, czyli możliwość wygenerowania takiego samego skrótu z dwóch różnych danych. Atak kolizyjny pozwala np. na podmianę oryginalnego pliku na inny z tym samym hashem – podważa to unikalność skrótu i uniemożliwia niezawodne wykrycie modyfikacji. Z tego powodu MD5 i SHA-1 nie są już uznawane za bezpieczne do celów kryptograficznych (np. podpisów cyfrowych czy sum kontrolnych), a w nowych zastosowaniach rekomenduje się używanie SHA-2, SHA-3 lub innych nowoczesnych funkcji skrótu.

Podsumowanie hash vs szyfrowanie: W przeciwieństwie do szyfrowania, hashowanie nie służy utajnianiu danych, ale zapewnianiu integralności i identyfikacji (np. plików czy haseł). Hash jest jednoznacznym odciskiem danych wejściowych, ale nie umożliwia ich odzyskania. Szyfrowanie zaś umożliwia odtworzenie oryginalnej informacji (deszyfrowanie) pod warunkiem posiadania odpowiedniego klucza. Te dwie techniki spełniają zatem inne role – hash chroni przed niezauważalną modyfikacją danych, a szyfrowanie przed ich odczytaniem przez niepowołanych.

Szyfrowanie danych – symetryczne i asymetryczne

Po co szyfrujemy dane? Szyfrowanie to proces przekształcania tekstów jawnych (czytelnych danych) na szyfrogramy (ciphertext) – czyli formę nieczytelną dla postronnych. Celem jest zachowanie poufności informacji, aby dostęp do oryginalnej treści mieli tylko uprawnieni odbiorcy. W odróżnieniu od funkcji skrótu, szyfrowanie jest odwracalne – mając adekwatny klucz można odszyfrować dane do postaci pierwotnej. Istnieją jednak dwa zasadniczo odmienne modele szyfrowania: symetryczne (gdzie używamy tego samego klucza po obu stronach) oraz asymetryczne (gdzie używany jest klucz publiczny i prywatny).

Szyfrowanie symetryczne (AES i inne)

W szyfrowaniu symetrycznym ten sam sekret klucz służy zarówno do zaszyfrowania, jak i odszyfrowania danych. Przykładowo, jeżeli ustalimy z drugą osobą hasło „XYZ”, możemy nim zaszyfrować plik – i ta sama wartość „XYZ” będzie potrzebna, aby go odszyfrować. Algorytmy symetryczne są cenione za wysoką efektywność: operacje szyfrowania/deszyfrowania są szybkie i dobrze skalują się do dużych ilości danych. Dlatego szyfrowanie symetryczne jest używane wszędzie tam, gdzie trzeba chronić duże zbiory informacji – od szyfrowania dysków i backupów, przez VPN i komunikację sieciową, po zabezpieczanie połączeń Wi-Fi (np. protokół WPA2 korzysta z szyfrowania AES).

AES (Advanced Encryption Standard) to współczesny standard szyfrowania symetrycznego. AES jest algorytmem blokowym używającym różnych długości klucza (128, 192 lub 256 bitów). Zapewnia bardzo wysoki poziom bezpieczeństwa i szybkie działanie, dzięki czemu został zaadaptowany na szeroką skalę – od ochrony danych rządowych po codzienne zastosowania w przeglądarkach internetowych. Innymi historycznymi algorytmami symetrycznymi są m.in. DES/3DES (dziś już niezalecane z uwagi na niską bezpieczenstwo klucza 56-bit w DES) czy ChaCha20 (algorytm strumieniowy używany np. w protokołach internetowych jako alternatywa dla AES).

Wyzwanie: dystrybucja klucza. Szyfrowanie symetryczne wymaga, by nadawca i odbiorca posiadali ten sam tajny klucz. Problemem jest bezpieczne przekazanie klucza drugiej stronie – jeżeli ktoś przechwyci klucz w trakcie uzgadniania, będzie mógł odszyfrować całą komunikację. Historycznie często rozwiązywano to przez pre-shared key – uprzednią wymianę klucza bocznym kanałem (np. osobiście, telefonicznie) albo wprowadzenie go manualnie do obu urządzeń. W skali Internetu nie jest to praktyczne, dlatego korzystamy z metod hybrydowych: klucze symetryczne są uzgadniane dzięki mechanizmów kryptografii asymetrycznej lub specjalnych protokołów wymiany kluczy, o czym za chwilę.

Przykładowe narzędzia symetryczne: W systemach uniksowych do szyfrowania plików symetrycznie możemy użyć OpenSSL: np. polecenie openssl enc -aes-256-cbc -salt -in dane.txt -out dane.zaszyfrowane zaszyfruje plik dane.txt algorytmem AES-256-CBC, prosząc o podanie hasła (które posłuży za klucz). Odszyfrowanie odbywa się analogicznym poleceniem z parametrem -d. Alternatywnie, GnuPG (GPG) umożliwia szyfrowanie symetryczne dzięki hasła poleceniem gpg -c plik.txt (po czym program zapyta o hasło-klucz i utworzy zaszyfrowany plik plik.txt.gpg).

Szyfrowanie asymetryczne (kryptografia klucza publicznego)

Kryptografia asymetryczna, zwana też kryptografią klucza publicznego, rozwiązuje problem dystrybucji klucza, ale wprowadza inny model działania. Każdy uczestnik generuje parę kluczy: prywatny (trzymany w tajemnicy) oraz odpowiadający mu publiczny (udostępniany wszystkim). Klucz publiczny służy do zaszyfrowania danych przeznaczonych dla posiadacza odpowiadającego mu klucza prywatnego – tylko ten konkretny odbiorca (posiadający klucz prywatny) może je odszyfrować. Odwrotnie, kluczem prywatnym można podpisać cyfrowo wiadomość, a każdy posługując się kluczem publicznym nadawcy zweryfikuje podpis. Widać zatem, iż w modelu asymetrycznym szyfrowanie i deszyfrowanie wykorzystują dwa różne klucze, powiązane matematycznie.

RSA to najbardziej znany algorytm asymetryczny, oparty na trudności faktoryzacji dużych liczb pierwszych. Stosuje się go od lat 70. XX wieku m.in. w protokołach SSL/TLS, w wymianie kluczy sesyjnych oraz w narzędziach takich jak PGP/GPG. Typowe klucze RSA mają długość co najmniej 2048 bitów (dla wysokiego bezpieczeństwa w tej chwili często 3072 lub 4096 bit). RSA pozwala zarówno szyfrować (niewielkie) bloki danych, jak i tworzyć podpisy cyfrowe. Obok RSA coraz większą popularność zdobywa kryptografia oparta na krzywych eliptycznych (ECC) – algorytmy takie jak ECDSA (podpis cyfrowy) czy ECDH (wymiana kluczy) oferują porównywalne bezpieczeństwo przy krótszych kluczach, dzięki czemu operacje są szybsze i klucze zajmują mniej miejsca.

Zastosowanie szyfrowania asymetrycznego: Głównym atutem modelu asymetrycznego jest możliwość bezpiecznej wymiany kluczy oraz utwierdzenie tożsamości komunikujących się stron. Przykładowo, w protokole HTTPS przeglądarka pozyskuje klucz publiczny serwera (z certyfikatu X.509) i używa go do zaszyfrowania tajnego klucza sesji (tzw. premaster secret). Serwer odszyfrowuje go swoim kluczem prywatnym – w ten sposób obie strony uzgadniają wspólny sekret, nie ujawniając go nikomu w trakcie transmisji. Dalej komunikacja odbywa się już symetrycznie przy użyciu uzgodnionego klucza sesyjnego (to tzw. podejście hybrydowe). Innym przykładem jest szyfrowanie e-maili: nadawca, mając publiczny klucz odbiorcy, może zaszyfrować wiadomość tak, iż tylko odbiorca (ze swoim kluczem prywatnym) ją odczyta. Szyfrowanie asymetryczne zapewnia też mechanizm podpisu cyfrowego, pozwalając zweryfikować, iż wiadomość pochodzi od konkretnej osoby (posiadającej dany klucz prywatny) i nie została zmieniona.

Wady szyfrowania asymetrycznego: Największym minusem jest niższa wydajność. Operacje matematyczne na dużych kluczach (RSA, ECC) są znacznie wolniejsze od prostych operacji symetrycznych. Dlatego asymetrycznie rzadko szyfruje się duże pliki – zwykle używa się tego do uzgadniania sekretów lub szyfrowania bardzo małych porcji danych (np. kluczy symetrycznych, skrótów itp.). Po ustanowieniu wspólnego sekretu, resztę danych przesyła się już szyfrem symetrycznym (hybryda). Ponadto dochodzi kwestia zarządzania kluczami – każdy uczestnik musi bezpiecznie przechowywać swój klucz prywatny i dystrybuować publiczny. Pojawia się też zagadnienie zaufania do kluczy publicznych, którym zajmuje się PKI (o tym w dalszej części).

Przykładowe narzędzia asymetryczne: W OpenSSL wygenerujemy parę kluczy poleceniem: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out klucz_prywatny.pem (to utworzy klucz prywatny RSA 2048-bit). Publiczny klucz możemy wyodrębnić komendą openssl rsa -in klucz_prywatny.pem -pubout -out klucz_publiczny.pem. Narzędzie GnuPG z kolei umożliwia wygenerowanie kluczy (RSA lub ECC) poleceniem gpg --full-generate-key i zarządzanie nimi, a następnie szyfrowanie wiadomości dla danego odbiorcy: gpg --encrypt --recipient UID_odbiorcy plik.txt (w tle GPG pobierze klucz publiczny odbiorcy z bazy lub lokalnych kluczy).

Symetryczne vs asymetryczne – porównanie

Dla lepszego zobrazowania różnic między szyfrowaniem symetrycznym a asymetrycznym, poniżej zestawiamy ich cechy w formie tabeli:

CechaSzyfrowanie symetryczneSzyfrowanie asymetryczne

Klucze	Jeden tajny klucz współdzielony (ten sam do szyfrowania i deszyfrowania).	Para kluczy: publiczny (do szyfrowania) i prywatny (do deszyfrowania).
Dystrybucja klucza	Wymaga bezpiecznego przekazania klucza drugiej stronie (trudne na dużą skalę).	Publiczny klucz można udostępniać dowolnie; prywatny trzyma w tajemnicy. Rozwiązuje problem dystrybucji.
Wydajność	Bardzo wysoka – nadaje się do szyfrowania dużych ilości danych w locie.	Znacznie wolniejsze – stosowane głównie do małych danych (np. wymiany klucza, podpisu).
Przykładowe algorytmy	AES, DES, 3DES, ChaCha20	RSA, ECC (ECDSA, ECDH), ElGamal
Typowe zastosowania	Szyfrowanie dysków, baz danych, tuneli VPN, połączeń Wi-Fi, plików.	Uzgadnianie kluczy sesji w protokołach (TLS/SSL), szyfrowanie email, podpisy cyfrowe, certyfikaty.
Bezpieczeństwo	Bardzo wysokie, o ile klucz pozostaje tajny. Długość klucza rzędu 128-256 bit zapewnia odporność na brute-force.	Bardzo wysokie, opiera się na trudnych problemach matematycznych (np. faktoryzacja, dyskretna logarytmizacja). Wymaga dłuższych kluczy (2048+ bit RSA, 256 bit ECC).

Perfect Forward Secrecy i wymiana kluczy (DH/ECDH)

Wymiana kluczy Diffie-Hellmana: Zanim omówimy Perfect Forward Secrecy (PFS), warto zrozumieć klasyczny protokół Diffie-Hellmana (DH). Jest to metoda, która pozwala dwóm stronom uzgodnić wspólny tajny klucz poprzez publiczną komunikację, bez wcześniejszego dzielenia się sekretem. W dużym uproszczeniu, każda ze stron generuje losową wartość (swoją część klucza) i wymienia pewne przetworzone formy tych wartości. Następnie, wykorzystując własną część i otrzymaną od drugiej strony, każda ze stron może obliczyć ten sam współdzielony sekret. Siła protokołu polega na tym, iż klucz nigdy nie jest przesyłany bezpośrednio – podsłuchujący atakujący nie jest w stanie, na podstawie przechwyconych danych, wyliczyć uzgodnionego klucza (wynika to z trudności rozwiązania problemu logarytmu dyskretnego w dużych grupach liczb pierwszych). Wspólny sekret uzyskany metodą DH może posłużyć jako klucz symetryczny do dalszej szyfrowanej komunikacji.

ECDH – klucze na krzywych eliptycznych: Wariantem protokołu DH jest ECDH (Elliptic Curve Diffie-Hellman), wykorzystujący algebraiczne adekwatności krzywych eliptycznych. Z punktu widzenia użytkowania, ECDH spełnia tę samą rolę – uzyskanie wspólnego tajnego klucza – ale opiera się na innym problemie matematycznym (logarytm na krzywej eliptycznej), co pozwala na krótsze klucze przy zachowaniu wysokiego bezpieczeństwa. ECDH jest powszechnie stosowane we współczesnych protokołach (np. TLS 1.3) jako element uzgadniania klucza.

Doskonała poufność w przód (Perfect Forward Secrecy): Perfect Forward Secrecy, w uproszczeniu PFS, to cecha protokołu kryptograficznego gwarantująca, iż kompromitacja klucza długoterminowego nie zagrozi poufności wcześniej zaszyfrowanych sesji. W praktyce osiąga się to poprzez wykorzystywanie unikalnych, efemerycznych kluczy sesyjnych dla każdej sesji komunikacyjnej, które są niszczone zaraz po zakończeniu sesji. Dzięki temu, choćby jeżeli napastnik w przyszłości pozyska np. klucz prywatny serwera (klucz stały), nie będzie w stanie odszyfrować zapisanych wcześniej zaszyfrowanych rozmów czy transmisji, ponieważ każda z nich była zabezpieczona odrębnym kluczem sesyjnym, już nieistniejącym.

Inaczej mówiąc: PFS to ochrona wstecznej poufności. Wyobraźmy sobie, iż ktoś przechwycił dziś zaszyfrowaną komunikację i latami ją magazynuje, a za pewien czas zdoła wykraść klucz prywatny serwera. jeżeli komunikacja nie miała PFS, to mając teraz ten klucz prywatny, atakujący mógłby odszyfrować całą zarejestrowaną historię połączeń. jeżeli natomiast protokół zapewnia PFS (czyli używa unikalnych kluczy sesyjnych, np. negocjowanych przez ECDHE – Elliptic Curve Diffie-Hellman Ephemeral), to zdobycie statycznego klucza prywatnego nic nie da – wcześniejsze sesje pozostaną tajne. Dlatego we współczesnych protokołach bezpieczeństwa (HTTPS/TLS, VPN, komunikatory typu Signal) zawsze należy włączać PFS, wybierając odpowiednie algorytmy wymiany kluczy (DHE/ECDHE zamiast stałego RSA). Przykładowo, TLS 1.3 wymusza już stosowanie efemerycznych kluczy (ECDHE) dla każdej sesji, co czyni protokół z definicji odpornym na ujawnienie klucza serwera po fakcie.

Infrastruktura klucza publicznego (PKI) – certyfikaty i zaufanie

Szyfrowanie asymetryczne rozwiązuje problem bezpiecznej wymiany klucza, ale skąd wiemy, iż czyjś klucz publiczny rzeczywiście należy do tej osoby lub serwisu, za który się podaje? Tu do gry wchodzi Infrastruktura Klucza Publicznego (PKI) – cały ekosystem certyfikatów cyfrowych i urzę-dów certyfikacji (Certificate Authority), który zapewnia model zaufania w komunikacji elektronicznej.

PKI to system zarządzania tożsamościami i kluczami publicznymi. Jego sercem są certyfikaty X.509 – standaryzowane cyfrowe “dokumenty”, które wiążą tożsamość (nazwę domeny, dane organizacji lub osoby) z odpowiadającym jej kluczem publicznym. Certyfikat pełni rolę elektronicznego paszportu: zawiera m.in. informację o podmiocie (właścicielu certyfikatu), jego kluczu publicznym, nazwie wystawcy certyfikatu (urzędu certyfikacji, który go podpisał), okresie ważności oraz różnych rozszerzeniach określających przeznaczenie certyfikatu. Najważniejsze, iż certyfikat jest cyfrowo podpisany przez zaufany urząd certyfikacji (CA) – tym samym poświadcza, iż dany klucz publiczny faktycznie należy do deklarowanego podmiotu.

Urzędy certyfikacji (CA) i łańcuch zaufania

Certificate Authority (Urząd Certyfikacji) to zaufana instytucja, która wystawia certyfikaty X.509 po zweryfikowaniu tożsamości podmiotu o nie wnioskującego. Przykładowo, jeżeli firma chce uzyskać certyfikat dla domeny moja-firma.pl, zgłasza się do CA, dostarcza wymagane dowody (np. prawo do dysponowania domeną, dokumenty rejestrowe firmy) i generuje CSR (Certificate Signing Request) – żądanie podpisania certyfikatu zawierające m.in. jej klucz publiczny i nazwę domeny. Urząd certyfikacji, po pozytywnej weryfikacji, wystawia certyfikat – czyli podpisuje cyfrowo dostarczony CSR swoim kluczem prywatnym. Nowy certyfikat X.509 staje się tym samym zaufanym dokumentem: każdy, kto mu ufa, może pobrać zeń klucz publiczny domeny i mieć pewność, iż należy on do adekwatnej firmy (skoro certyfikat jest podpisany przez znany urząd).

Aby ten model zadziałał, musimy mieć zaufanie do urzędu certyfikacji. Rozwiązano to poprzez tzw. łańcuch zaufania (chain of trust). Istnieją Root CA – główne urzędy certyfikacji, którym z definicji ufają systemy operacyjne i przeglądarki (ich certyfikaty root są fabrycznie zapisane w magazynach zaufanych głównych urzędów w naszym systemie). Taki główny urząd może sam podpisywać certyfikaty użytkowników, ale częściej wydaje certyfikaty pośrednie (Intermediate CA) dla innych podmiotów, delegując im uprawnienia do wystawiania certyfikatów końcowych. Schemat ten tworzy hierarchiczny łańcuch certyfikatów: na szczycie mamy certyfikat root CA (samopodpisany, wszyscy mu ufają), pod nim jeden lub więcej certyfikatów pośrednich CA (podpisanych przez root), a na dole certyfikat końcowy (np. naszej strony WWW) podpisany przez jeden z pośrednich CA. Taki łańcuch jest dostarczany przeglądarce podczas nawiązywania połączenia HTTPS – przeglądarka weryfikuje podpis certyfikatu końcowego używając klucza publicznego z certyfikatu pośredniego, ten z kolei sprawdza w oparciu o klucz root itd., aż do zaufanego root CA, który jest w systemie. jeżeli cała ścieżka jest poprawna, certyfikat uznaje się za zaufany. Dzięki hierarchii zaufania użytkownik nie musi znać każdego serwisu – wystarczy, iż ufa głównemu urzędowi (który z kolei ręczy za pośrednie, a te za końcowe).

W praktyce komercyjnych CA jest wielu (DigiCert, Sectigo, Let’s Encrypt itd.), ale wszystkie ich główne certyfikaty root są zawarte w popularnych systemach, co umożliwia automatyczne rozpoznawanie certyfikatów stron i usług.

Certyfikaty X.509 – struktura i rozszerzenia (CSR, SAN itp.)

Certyfikat X.509 zawiera szereg pól informacyjnych. Najważniejsze z nich to:

• Subject (Podmiot): Dane identyfikujące właściciela certyfikatu. Dla certyfikatów SSL jest to zwykle CN (Common Name) określający nazwę domeny (np. CN=moja-firma.pl). W certyfikatach osobistych to może być imię i nazwisko, email itp.
• Issuer (Wystawca): Nazwa urzędu certyfikacji, który podpisał certyfikat (jego Subject).
• Validity (Okres ważności): Daty „not before” i „not after” określające przedział czasu, w którym certyfikat jest ważny. Po upływie ważności certyfikat wygasa i nie powinien być używany.
• Public Key (Klucz publiczny podmiotu): adekwatny klucz publiczny właściciela, który certyfikat poświadcza.
• Signature (Podpis cyfrowy wystawcy): Podpis CA, który umożliwia weryfikację autentyczności certyfikatu.
• Serial Number (Numer seryjny): Unikalny numer nadany przez CA, używany m.in. przy unieważnianiu.
• Extensions (Rozszerzenia): M.in. Key Usage (do czego służy certyfikat – np. tylko do podpisów, tylko do szyfrowania, autoryzacji serwera itp.), Extended Key Usage, oraz bardzo istotny Subject Alternative Name (SAN). SAN pozwala przypisać do certyfikatu wiele nazw naraz – np. certyfikat dla moja-firma.pl może mieć w SAN także www.moja-firma.pl i inne subdomeny. w tej chwili przeglądarki wymagają wpisywania nazwy domeny właśnie w polu SAN (pole CN jest traktowane historycznie).

Certyfikat X.509 najczęściej powstaje w procesie: wygenerowania pary kluczy przez podmiot, stworzenia CSR zawierającego klucz publiczny i żądane informacje (nazwa domeny itp.), wysłania CSR do CA, weryfikacji przez CA, a następnie podpisania i wydania adekwatnego certyfikatu. Samo CSR (Certificate Signing Request) jest plikiem tekstowym w kodowaniu PEM, którego zawartość to m.in. klucz publiczny i distinguished name podmiotu. CSR również może zostać wygenerowane poleceniem OpenSSL, np.:

openssl req -new -key klucz_prywatny.pem -out zadanie.csr -subj "/C=PL/ST=Mazowieckie/L=Warszawa/O=Moja Firma/CN=moja-firma.pl"

(gdzie podaliśmy minimalne pola: kraj, województwo, lokalizację, organizację i nazwę CN). Taki plik .csr wysyłamy do CA. Po otrzymaniu certyfikatu od CA, możemy obejrzeć jego zawartość poleceniem:

openssl x509 -in moj_cert.crt -text -noout

które wyświetli wszystkie powyższe pola, w tym listę rozszerzeń (SAN, Key Usage itp.).

Unieważnianie certyfikatów – CRL i OCSP

Certyfikaty mają ograniczony czas ważności (zwykle 1 rok lub krócej), ale mogą też zostać unieważnione (revoked) przed czasem – np. w przypadku kompromitacji klucza prywatnego podmiotu lub błędnego wydania. Gdy certyfikat zostanie odwołany, należy poinformować o tym użytkowników, by już mu nie ufali. Służą do tego dwa mechanizmy: CRL oraz OCSP.

CRL (Certificate Revocation List) to lista unieważnionych numerów seryjnych certyfikatów publikowana periodycznie przez każdy urząd certyfikacji. CRL to po prostu plik (podpisany przez CA), który klient może pobrać i sprawdzić, czy dany certyfikat (po numerze seryjnym) figuruje na liście odwołanych. Wadą CRL jest rozmiar listy i fakt, iż nie jest ona w czasie rzeczywistym – dlatego powstał mechanizm OCSP (Online Certificate Status Protocol). OCSP działa na zasadzie zapytanie-odpowiedź: klient (np. przeglądarka) kontaktuje się z serwerem OCSP (uruchamianym przez wystawcę certyfikatu) i pyta o status konkretnego numeru seryjnego. Serwer odpowiada statusem „good” (ważny), „revoked” (unieważniony) lub „unknown”. Dzięki OCSP przeglądarka może w kilka chwil dowiedzieć się, czy certyfikat strony nie został np. wczoraj unieważniony z powodu kradzieży klucza. Nowoczesne przeglądarki implementują choćby OCSP Stapling – mechanizm, gdzie to serwer podczas nawiązywania połączenia od razu dołącza świeżą podpisaną odpowiedź OCSP potwierdzającą ważność swojego certyfikatu, dzięki czemu przeglądarka nie musi osobno kontaktować się z CA.

Jeśli certyfikat jest unieważniony lub wygasł, klient powinien odmówić komunikacji zaszyfrowanej z takim podmiotem. Przeglądarki w takiej sytuacji wyświetlają ostrzeżenia o braku zaufania (czerwony komunikat o niebezpiecznym certyfikacie). Dlatego tak istotne jest monitorowanie terminów ważności certyfikatów oraz natychmiastowe odwoływanie ich w razie incydentów bezpieczeństwa.

Uwaga: Zarządzanie PKI bywa złożone, ale korzystanie z niej na co dzień jest dla użytkownika niemal transparentne – np. podczas wizyty na stronie HTTPS przeglądarka automatycznie weryfikuje certyfikat i łańcuch zaufania. Wiele usług oferuje darmowe certyfikaty (np. Let’s Encrypt automatyzuje generowanie i odnawianie certyfikatów SSL/TLS), co ułatwia wdrażanie szyfrowania. Pamiętajmy, iż choćby najlepsze szyfrowanie zda się na nic, jeżeli ktoś mógłby podszyć się pod naszego rozmówcę – PKI chroni przed takim scenariuszem.

Przykładowe polecenia CLI dla kryptografii

Na koniec zebraliśmy kilka użytecznych poleceń w środowisku Linux, demonstrujących omawiane techniki kryptograficzne:

• Obliczanie skrótu SHA-256 pliku: sha256sum plik.txt (Zwróci 64-znakowy hash; opcja -b doda tryb binarny, a -c pozwoli sprawdzić plik z listą sum kontrolnych).
• Symetryczne szyfrowanie pliku hasłem (AES-256-CBC): openssl enc -aes-256-cbc -salt -in tajne_dane.txt -out zaszyfrowane.dat (Program zapyta o hasło, które posłuży jako klucz; odszyfrować można dodając -d i podając to samo hasło).
• Wygenerowanie klucza RSA 2048 bit: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out klucz_prywatny.pem (Tworzy klucz prywatny PEM; klucz publiczny wyodrębnimy poleceniem openssl rsa -in klucz_prywatny.pem -pubout -out klucz_publiczny.pem).
• Szyfrowanie pliku kluczem publicznym (RSA): openssl rsautl -encrypt -inkey klucz_publiczny.pem -pubin -in wiadomość.txt -out zaszyfrowane.bin (Zaszyfruje zawartość pliku wiadomość.txt kluczem publicznym; odszyfrowanie: openssl rsautl -decrypt -inkey klucz_prywatny.pem -in zaszyfrowane.bin).
• Generowanie żądania certyfikatu (CSR): openssl req -new -newkey rsa:2048 -nodes -keyout klucz.pem -out wniosek.csr -subj "/CN=moja-domena.pl/O=Moja Firma/C=PL" (Tworzy nowy klucz prywatny oraz plik CSR ze wskazanymi danymi podmiotu; opcja -nodes oznacza brak szyfrowania klucza hasłem dla uproszczenia).
• Sprawdzenie informacji o certyfikacie X.509: openssl x509 -in certyfikat.pem -noout -text (Wyświetli szczegóły certyfikatu w formie tekstowej – subject, issuer, daty ważności, rozszerzenia, itp.).
• Szyfrowanie pliku GPG dla odbiorcy (asymetryczne): gpg --encrypt --recipient "Użytkownik <email@example.com>" raport.pdf (Zakładając, iż posiadamy klucz publiczny odbiorcy w naszym magazynie GPG, utworzy zaszyfrowany plik raport.pdf.gpg czytelny tylko dla posiadacza pasującego klucza prywatnego).
• Tworzenie i odczyt podpisu cyfrowego (GPG): gpg --sign dokument.txt # tworzy dokument.txt.gpg (zaszyfrowany podpis) gpg --verify dokument.txt.gpg # weryfikuje podpis, korzystając z klucza publicznego podpisującego

Powyższe polecenia to jedynie wierzchołek góry lodowej, ale ilustrują praktyczne wykorzystanie omówionych technologii. W realnych zastosowaniach korzysta się także z zaawansowanych narzędzi do zarządzania PKI (np. keytool dla Java Keystore, certmgr w Windows, czy dedykowane oprogramowanie HSM do ochrony kluczy prywatnych).

Praktyczne zastosowania i zalecenia

Dobór metody ochrony danych: W zależności od scenariusza należy wybrać odpowiednie narzędzie kryptograficzne. jeżeli chcemy zapewnić poufność przechowywanych lub przesyłanych informacji (aby nikt poza uprawnionymi nie poznał treści), musimy sięgnąć po szyfrowanie. Z kolei gdy zależy nam na kontroli integralności i autentyczności danych (aby wykryć wszelkie zmiany lub upewnić się co do źródła), stosujemy funkcje skrótu oraz podpisy cyfrowe. Często obie te metody idą w parze – np. w komunikacji TLS dane są szyfrowane dla poufności, a jednocześnie zabezpieczone kodem MAC (opartym o funkcję skrótu z kluczem) dla spójności i uwierzytelnienia.

Ochrona danych w spoczynku vs w tranzycie: Dla danych w spoczynku (ang. at rest, np. na dysku, w bazie) typowym podejściem jest szyfrowanie symetryczne – np. całego dysku (Full Disk Encryption, BitLocker/veracrypt na PC, LUKS/dm-crypt na Linux) lub konkretnych plików/backupów. Klucze do takich danych muszą być dobrze chronione (np. hasłem użytkownika lub w module TPM). Dla danych w tranzycie (ang. in transit, czyli przesyłanych przez sieć) stosujemy protokoły szyfrowane – jak HTTPS, SSH, VPN (WireGuard, OpenVPN) – które wykorzystują kryptografię asymetryczną do uzgodnienia kluczy i symetryczną do szyfrowania samego ruchu. Należy upewnić się, iż konfiguracje wymuszają algorytmy z PFS – np. w serwerze WWW włączyć tylko pakiety szyfrujące TLS z ECDHE (co zapewnia Perfect Forward Secrecy).

Aktualne algorytmy i długości kluczy: Kryptografia to dziedzina ciągle ewoluująca. Zalecane jest używanie współczesnych, silnych algorytmów: AES (128 lub 256 bit) zamiast przestarzałego DES/3DES, protokoły TLS 1.2/1.3 zamiast SSL, RSA co najmniej 2048 bit (lub lepiej ECC 256 bit) zamiast krótkich kluczy, SHA-256/SHA-3 zamiast MD5/SHA-1. Regularnie należy śledzić zalecenia organizacji standaryzujących (NIST, IETF) oraz branżowe (OWASP) odnośnie bezpiecznych algorytmów, bo to co dziś jest bezpieczne, za kilka lat może okazać się niewystarczające (na horyzoncie widać np. komputery kwantowe, które mogą zagrozić obecnym metodom asymetrycznym).

Bezpieczne zarządzanie kluczami i certyfikatami: Silny algorytm to jedno, ale równie ważna jest ochrona samych kluczy prywatnych. Należy je przechowywać w bezpiecznym miejscu (zaszyfrowane magazyny, moduły sprzętowe HSM, TPM na płytach głównych) i ograniczać do nich dostęp. W kontekście certyfikatów, trzeba monitorować daty ich wygaśnięcia i odnawiać na czas, aby nie doprowadzić do przerwy w zaufaniu. Dobrą praktyką jest też wdrożenie OCSP Stapling na serwerach WWW, by przyspieszyć weryfikację certyfikatów u klientów.

Hasła i skróty w aplikacjach: jeżeli tworzymy aplikację wymagającą przechowywania haseł, nigdy nie zapisujemy haseł w postaci jawnej. Zamiast tego hasła powinny być haszowane (np. algorytmem z rodziny SHA-2 lub, jeszcze lepiej, funkcją key derivation typu bcrypt/argon2, zoptymalizowaną do przechowywania haseł) wraz z unikalną solą per użytkownik. Pozwala to zabezpieczyć bazę haseł choćby w razie wycieku.

Podsumowanie zastosowań:

• Używaj hashy do: weryfikacji integralności plików (np. po pobraniu), przechowywania haseł, tworzenia podpisów cyfrowych (w połączeniu z kluczami prywatnymi).
• Używaj szyfrowania symetrycznego do: ochrony danych w bazach, na dyskach, w archiwach – wszędzie tam, gdzie ten sam podmiot szyfruje i deszyfruje.
• Używaj szyfrowania asymetrycznego do: wymiany kluczy, bezpiecznej komunikacji między różnymi podmiotami (np. klient-serwer), szyfrowania komunikacji e-mail, autoryzacji (certyfikaty, podpisy).
• Stosuj PKI gdy potrzebujesz zaufania na dużą skalę: certyfikaty SSL/TLS dla serwisów internetowych, podpis kwalifikowany dla dokumentów elektronicznych, itp., bazując na zaufanych urzędach certyfikacji.
• W protokołach sieciowych zawsze włącz Perfect Forward Secrecy (PFS) – zapewni to, iż kompromitacja klucza serwera nie ujawni historii komunikacji.
• Starannie dobieraj algorytmy i klucze, kierując się aktualnymi rekomendacjami bezpieczeństwa, a przestarzałe metody wyłączaj w konfiguracjach.

Podsumowanie

Hashowanie i szyfrowanie to dwa filary kryptografii – każdy o innym przeznaczeniu. Funkcje skrótu gwarantują spójność i identyfikowalność danych, podczas gdy szyfrowanie zapewnia poufność informacji. Razem z mechanizmami wymiany kluczy (DH/ECDH) i koncepcją Perfect Forward Secrecy tworzą podstawę bezpiecznej komunikacji. Nad wszystkim czuwa Infrastruktura Klucza Publicznego, dostarczając zaufania poprzez certyfikaty i podpisy cyfrowe. Poznanie tych technologii i umiejętne ich wykorzystanie pozwala inżynierom IT skutecznie chronić dane – zarówno podczas transmisji, jak i w spoczynku – co we współczesnym świecie ciągłych zagrożeń jest umiejętnością nie do przecenienia. Bez względu na to, czy jesteś początkującym administratorem, czy programistą, solidna wiedza z zakresu kryptografii i PKI jest kluczowa dla tworzenia bezpiecznych systemów i aplikacji. Uzbrojony w tę wiedzę, wiesz już co stosować, kiedy to robić i po co, aby adekwatnie zabezpieczyć informacje w swojej organizacji.

Zapisz się też na bezpłatne szkolenie VOD – LPI Security Essentials, gdzie znajdziesz egzaminy próbne, prace domowe i checklisty przygotowujące do egzaminu.