Kryptografia i PKI dla Security+: O czym naprawdę musisz myśleć

Podczas ćwiczenia tabletop prawnik pyta, czy przesłane e-mailem pliki PDF z umowami zostały naruszone. Inżynieria odpowiada: „Były pobierane przez TLS, więc jesteśmy OK." Zatrzymujesz się: TLS chroni w tranzycie, nie po zapisaniu. Prawnik potrzebuje integralności w spoczynku i niezaprzeczalności na podpisach — nie „HTTPS był zielony." Pytania kryptograficzne SY0-701 wyglądają jak ciekawostki, dopóki nie obudujesz ich ramą właściwość + cykl życia + opieka nad kluczami. Ten post obejmuje to, o czym musisz rozumować: szyfrowanie a hashowanie, symetryczne a asymetryczne, tryby szyfrów blokowych, podpisywanie kodu, przechowywanie kluczy i cykl życia PKI — bez zamieniania się w podręcznik matematyczny.

Wybierz narzędzie według właściwości bezpieczeństwa

Każde pytanie kryptograficzne w SY0-701 zapowiada odpowiedź w pierwszym zdaniu, jeśli słuchasz celu. Poufność, integralność, uwierzytelnianie, niezaprzeczalność — każda pociąga w kierunku innej rodziny narzędzi, a ich pomieszanie to sposób, w jaki czynnik rozpraszający staje się twoją odpowiedzią.

Gdy trzeba utrzymać treść w sekrecie, odpowiedzią jest szyfrowanie — symetryczne dla danych masowych, asymetryczne dla wymiany kluczy. Gdy trzeba wykryć manipulację, sięgasz po hash lub podpis cyfrowy; samo szyfrowanie nie dowodzi, że szyfrogram dotarł nienaruszony. Gdy trzeba weryfikować hasła bez ich przechowywania, poprawne jest solone wolne KDF — nie zwykły AES, bo wtedy zarządzanie kluczami staje się pojedynczym punktem awarii. Gdy trzeba jednocześnie dowieść tożsamości nadawcy i integralności, tylko podpis cyfrowy z parą asymetryczną zapewnia niezaprzeczalność; symetryczny MAC nie może powiedzieć, która strona posiadająca współdzielony klucz napisała wiadomość.

Tokenizacja zastępuje wrażliwe dane surogacją mapowaną w bezpiecznym magazynie — przydatna w projektach PCI, gdzie systemy podrzędne potrzebują odniesienia, ale nie surowego PAN. Maskowanie danych (data masking) pokazuje zredagowane wartości w środowiskach niższych. Żadne z nich nie jest szyfrowaniem, a egzamin sprawdza, czy potrafisz je odróżnić.

Symetryczne a asymetryczne — i dlaczego prawdziwe protokoły hybrydyzują

Algorytmy symetryczne używają jednego współdzielonego sekretu do szyfrowania i deszyfrowania. AES to egzaminacyjny punkt odniesienia — wystarczająco szybki, by zaszyfrować wielogigabajtową kopię zapasową w sekundy, odpowiedni dla danych masowych. Trudnym problemem jest dystrybucja: jak dwoje obcych może podzielić się sekretem bez odczytu przez atakującego kanału?

Algorytmy asymetryczne — RSA i rodzina ECC — rozwiązują to przez podział klucza na publiczną i prywatną połowę. Szyfrujesz kluczem publicznym odbiorcy; tylko jego klucz prywatny może odszyfrować. Podpisujesz swoim kluczem prywatnym; każdy z twoim kluczem publicznym może zweryfikować. Matematyka jest wolna, więc prawdziwe protokoły hybrydyzują: operacje asymetryczne obsługują dowód tożsamości i uzgodnienie kluczy przy nawiązywaniu sesji, a następnie symetryczny klucz przenosi ruch masowy.

TLS to kanoniczny przykład. Podczas handshake serwer prezentuje swój certyfikat, klient weryfikuje łańcuch wstecz do zaufanego CA, a obie strony uzgadniają materiał kluczujący przez matematykę asymetryczną. Gdy istnieje klucz sesji, każdy bajt aplikacji podróżuje pod AES-GCM. Faza asymetryczna jest wystarczająco droga, by pełzać, gdyby była używana na każdej odpowiedzi; faza symetryczna jest wystarczająco szybka, by wideo strumieniowe działało niezauważalnie.

Forward secrecy (utajnienie wyprzedzające) wchodzi do gry, gdy egzamin wspomina efemeryczne Diffie-Hellman (ECDHE). Jeśli długoterminowy klucz prywatny serwera wycieknie później, atakujący, który nagrał stare sesje, nie może ich odszyfrować — bo efemeryczny klucz był odrzucany po handshake. To właściwość, którą chronią nowoczesne konfiguracje TLS.

Pułapka egzaminacyjna: „Co szyfruje szybciej dla strumienia kopii zapasowej 10 GB?" ląduje na symetrycznym. „Co dowodzi tożsamości serwera w HTTPS?" ląduje na zaufaniu do certyfikatu asymetrycznego, a następnie symetrycznym masowym.

Przestarzałe i słabe algorytmy — wiesz, co wycofać

SY0-701 sprawdza, czy rozpoznajesz algorytmy, które zostały złamane lub spadają poniżej nowoczesnych marginesów bezpieczeństwa. To nie historyczna ciekawostka; regulatorzy wymieniają tę listę w kwestionariuszach audytów, a treści egzaminacyjne często przedstawiają „wymóg zgodności ze starszymi systemami" jako czynnik rozpraszający.

Gdy treść opisuje starszą aplikację obsługującą tylko 3DES lub SSLv3, „włącz dla kompatybilności" to czynnik rozpraszający. Mocna odpowiedź obejmuje izolację sieciową i udokumentowaną kontrolkę kompensującą podczas trwania remediacji — nigdy „wsteczna kompatybilność" jako odpowiedź permanentna.

Tryby szyfrów: dlaczego ECB zawodzi, a GCM wygrywa

Szyfry blokowe działają w trybach, które określają, jak obsługują plaintext dłuższy niż jeden blok. Nie musisz ich implementować, ale ulubiony kontrast egzaminu warto rozumieć prostym językiem.

ECB (Electronic Code Book) szyfruje każdy blok niezależnie tym samym kluczem. Konsekwencją jest to, że identyczne bloki plaintext produkują identyczne bloki szyfrogram, więc wzorce w oryginalnych danych przeżywają nienaruszony przejście do zaszyfrowanego wyjścia. Klasyczna ilustracja to szyfrowanie obrazu bitmapowego w trybie ECB i obserwowanie, jak kształt oryginalnego obrazu pozostaje rozpoznawalny przez szyfrogram. ECB jest błędny dla prawie każdego rzeczywistego zastosowania, i SY0-701 to wie.

GCM (Galois/Counter Mode) łączy szyfrowanie trybu licznikowego z kodem uwierzytelniania wiadomości Galois, zapewniając poufność, integralność i uwierzytelnianie w jednym przebiegu. To tryb szyfru za obowiązkowymi zestawami szyfrów TLS 1.3. Gdy treść pyta, który tryb zastosować dla API, które potrzebuje zarówno prywatności, jak i wykrywania manipulacji, szyfrowanie uwierzytelnione klasy GCM to mocna odpowiedź.

Podpisywanie kodu i S/MIME — zastosowane zaufanie asymetryczne

Podpisywanie kodu (code signing) to kryptografia asymetryczna zastosowana do dystrybucji oprogramowania. Deweloper podpisuje plik binarny swoim kluczem prywatnym; system operacyjny lub sklep z aplikacjami weryfikuje podpis względem certyfikatu dewelopera przed dopuszczeniem do wykonania. Jeśli podpis brakuje lub certyfikat jest unieważniony, nowoczesne platformy ostrzegają lub odmawiają uruchomienia. Właściwość bezpieczeństwa w grze to integralność i autentyczność, nie poufność — nikt nie szyfruje publicznego instalatora. Celem jest udowodnienie, że plik binarny pochodzi od podanego wydawcy i nie był modyfikowany po podpisaniu.

Ataki na łańcuch dostaw często celują precyzyjnie w ten krok, bo ważny podpis jest tak potężny. Skompromituj klucz podpisujący lub certyfikat, a możesz dystrybuować malware pod zaufaną nazwą. Dlatego prywatne klucze do podpisywania kodu należą do HSM, a nie na laptopy deweloperów ze współdzielonym dostępem do systemu plików. Egzamin używa podpisywania kodu, by testować rozróżnienie integralność a poufność: podpisanie dowodzi proweniencji; szyfrowanie ukrywa treść. To różne narzędzia dla różnych właściwości.

S/MIME przenosi tę samą maszynerię asymetryczną do poczty e-mail. Nadawca podpisuje wychodzącą wiadomość swoim kluczem prywatnym; odbiorcy weryfikują za pomocą opublikowanego certyfikatu nadawcy. Ten podpis dowodzi, że treść wiadomości dotarła nienaruszony i że tylko posiadacz tego klucza prywatnego mógł ją stworzyć — wspierając niezaprzeczalność w sposób, jakiego nagłówki transportu TLS nigdy nie mogą zapewnić, bo TLS zabezpiecza kanał, podczas gdy S/MIME zabezpiecza obiekt. S/MIME może też szyfrować e-mail: nadawca szyfruje kluczem publicznym każdego odbiorcy, tak żeby tylko ci odbiorcy mogli odszyfrować. Kompromis to złożoność zarządzania certyfikatami — każdy uczestnik potrzebuje ważnego certyfikatu, który musi być dystrybuowany i wzajemnie zaufany. SY0-701 używa S/MIME do testowania rozróżnienia niezaprzeczalność a poufność, nie szczegółów implementacyjnych.

Gdzie żyją klucze: TPM, HSM, KMS i secure enclave

Najważniejszą właściwością do zidentyfikowania w pierwszej kolejności jest to, czy klucz może opuścić sprzęt. Z tego ograniczenia wynika właściwe narzędzie.

TPM (Trusted Platform Module) to chip przylutowany do płyty głównej. Klucze tam wygenerowane są związane z tą platformą — z założenia nie powinny być eksportowane do innej maszyny. Egzaminacyjny scenariusz to szyfrowanie pełnego dysku: BitLocker zapieczętowuje klucz woluminu do TPM i opcjonalnie PIN, więc wyjęcie dysku i podłączenie go gdzie indziej daje zaszyfrowany szum. TPM to zakorzenione zaufanie do platformy, nie korporacyjne urządzenie podpisujące.

HSM (Hardware Security Module) to urządzenie lub karta PCIe do wysokozapewnieniowych operacji kryptograficznych w skali. Urzędy certyfikacji używają HSM do podpisywania certyfikatów, tak żeby klucz prywatny głównego CA nigdy nie dotykał oprogramowania ogólnego przeznaczenia; pipelines podpisywania kodu powinny też przez nie przechodzić. Klucze są nieeksportowalne; operacje są rejestrowane i separowane według ról. HSM to odpowiedź, gdy treść mówi „klucz prywatny nigdy nie może opuścić sprzętu" w skali korporacyjnej lub CA.

KMS (Key Management Service) to słownictwo epoki chmurowej dla scentralizowanego zarządzania cyklem życia kluczy — tworzenie, rotacja, unieważnianie i audyt kluczy chroniących dane w spoczynku. Szyfrowanie kopertowe (envelope encryption) w chmurze używa klucza szyfrowania kluczy (KEK) zarządzanego przez KMS do zawijania kluczy szyfrowania danych (DEK); rotacja KEK re-szyfruje DEK bez dotykania surowych danych. Egzamin sprawdza, czy klucze KMS zarządzane przez klienta różnią się od zarządzanych przez dostawcę: kontrola nad KEK oznacza kontrolę nad tym, czy deszyfrowanie w ogóle może nastąpić.

Secure enclave zapewnia izolowane wykonanie CPU — w głębokości egzaminacyjnej Intel SGX — tak żeby kod wewnątrz enklawy nie mógł być inspekcjonowany nawet przez OS. Scenariusz to ochrona kluczy podczas użytkowania, nie tylko w spoczynku.

Pułapka pojawiająca się w każdym cyklu egzaminacyjnym: TPM nie równa się HSM. TPM jest przymocowany do platformy i odpowiada na pytanie „czy stan boot tego laptopa był czysty i nienaruszony?" HSM to urządzenie korporacyjne i odpowiada na pytanie „kto może autoryzować operację podpisywania CA i jak jest to rejestrowane?"

PKI: łańcuch, unieważnianie i cykl życia

Infrastruktura kluczy publicznych (Public Key Infrastructure) wiąże tożsamości z kluczami publicznymi przez certyfikaty podpisane przez Urzędy Certyfikacji. Łańcuch zaufania biegnie od głównego CA — kotwicy zaufania z podpisem własnym dostarczanej w magazynach zaufania systemu operacyjnego i przeglądarki — przez jeden lub więcej pośrednich CA do certyfikatu liścia identyfikującego serwer, użytkownika lub urządzenie. Awaria w jakimkolwiek ogniwie tego łańcucha — wygasły pośredni, unieważniony liść, niezgodna nazwa hosta — przerywa walidację.

Unieważnianie to miejsce, gdzie egzamin ukrywa znaczącą złożoność. CRL (Certificate Revocation List) to plik publikowany przez CA z unieważnionymi numerami seryjnymi; klienci pobierają i sprawdzają go, ale lista może być spóźniona o godziny. OCSP pozwala klientowi w czasie rzeczywistym zapytać CA o status konkretnego certyfikatu — świeższe, ale dodaje zależność sieciową. OCSP stapling sprawia, że serwer dołącza do handshake TLS ostatnią podpisaną odpowiedź OCSP, więc klient uzyskuje świeżość bez bezpośredniego kontaktowania się z CA. Egzamin rozróżnia je na podstawie kompromisu, który każda przedstawia.

Wygasły certyfikat i unieważniony certyfikat oba nie przechodzą walidacji, ale remediacja różni się: odnów wygasły certyfikat; ponownie wydaj i usuń zaufanie dla unieważnionego. CSR to to, co podmiot składa do urzędu, żeby certyfikować swój klucz publiczny. Certyfikaty wieloznaczne (*.example.com) pokrywają subdomeny, ale zwiększają promień rażenia (blast radius) jeśli klucz prywatny wycieknie; certyfikaty SAN wymieniają wyraźne nazwy i stanowią obecną praktykę.

Escrow kluczy (key escrow) przechowuje kopię kluczy prywatnych u zaufanego powiernika w celu odzyskania — przydatne gdy pracownik odchodzi bez przekazania kluczy, ale wprowadza powiernika jako potencjalną powierzchnię ataku lub wywierania presji. SY0-701 ujmuje to jako kompromis, a nie rekomendację.

Zakres szyfrowania: w spoczynku, w tranzycie, w użyciu

TLS w sieci nie chroni pliku siedzącego na serwerze po jego odszyfrowaniu i zapisaniu. Szyfrowanie pełnego dysku chroniące wyłączony laptop nie pomaga, gdy OS jest uruchomiony i deszyfrowanie jest aktywne. Treści egzaminacyjne często konstruują scenariusze wokół niedopasowania zakresu — wdrożona kontrolka nie obejmuje zagrożenia w incydencie. Skradziony laptop z FDE i silnym PIN-em przed booten jest chroniony w spoczynku, jeśli był wyłączony gdy go zabrano; TLS do aplikacji chmurowych jest nieistotny dla offline'owej forensyki dysku, jeśli FDE nigdy nie był skonfigurowany. Dopasuj zakres kontrolki do zakresu zagrożenia, a większość tych scenariuszy rozwiązuje się przejrzyście.

Podsumowanie pułapek egzaminacyjnych

Podsumowanie

Sukces kryptograficzny w Security+ to jakość decyzji, nie zapamiętywanie rozmiarów bloków ani lat wycofywania algorytmów. Gdy prawnik pyta o sfałszowane PDF-y, odpowiadasz podpisami i hashami, wyjaśniasz zakres TLS i wskazujesz na podpisywanie wsparte HSM, jeśli niezaprzeczalność musi przetrwać spór. Gdy inżynieria chce „po prostu zaszyfrować hasła", wyjaśniasz, dlaczego istnieją solone KDF i co by kosztowało zarządzanie kluczami. Gdy treść wspomina tryb ECB lub RC4, nazywasz właściwość, która zawodzi, i to, co ją zastępuje. Ten wzorzec rozumowania — najpierw właściwość, potem narzędzie, zawsze zakres — jest dokładnie tym, co nagradza SY0-701.

Dodatkowe lektury: post Kontrolki bezpieczeństwa, CIA i AAA dla ramy klasyfikacji kontrolek leżącej u podstaw każdej decyzji kryptograficznej, oraz post Ochrona danych i odporność dla zakresu szyfrowania zastosowanego do scenariuszy kopii zapasowych i ciągłości.