Kryptografia i PKI dla Security+: o czym naprawdę musisz rozumieć

Podczas tabletop legal pyta, czy wysłane mailem PDF-y umów były zmieniane. Inżynieria mówi: „Pobraliśmy przez TLS, więc OK.” Zatrzymujesz się: TLS chroni w tranzycie, nie po zapisaniu. Legal potrzebuje integralności at rest i non-repudiation podpisów — nie „HTTPS był zielony”. Pytania krypto na SY0-701 brzmią jak trivia, dopóki nie ujmiesz ich jako decyzji właściwość + cykl życia + custody kluczy. Ten wpis: encryption vs hash, symetryczne vs asymetryczne, przechowywanie kluczy, PKI, pułapki — bez podręcznika matematyki.

Cele najpierw: narzędzie według właściwości

Tokenizacja zastępuje wrażliwe dane tokenem mapowanym w sejfie — typowe w PCI. Data masking pokazuje zredagowane/fikcyjne wartości w niższych środowiskach. Żadne nie zastępuje „szyfruj wszystko tak samo”.

Przykład: wyciek bazy haseł

Wyciek user_table z username, password_hash. Hash unsalted SHA-256.

• Utrata: poufność credentiali (offline cracking).
• Kierunek naprawy: unikalny salt + slow KDF (bcrypt, scrypt, Argon2) — nie „zaszyfruj kolumnę hash AES” (key mgmt staje się nowym SPOF).
• Kąt egzaminu: „Encrypt passwords” prawie zawsze źle; hash with salt to wzorzec.

Szyfrowanie symetryczne vs asymetryczne

Symetryczne (AES — typowy odniesienie egzaminu) używa jednego współdzielonego klucza. Szybkie na duże dane. Trudność: jak przekazać klucz bez podsłuchu?

Asymetryczne (RSA, ECC) — para kluczy: publiczny szyfruje/weryfikuje; prywatny odszyfrowuje/podpisuje. Rozwiązuje dystrybucję i tożsamość. Wolniejsze — protokoły hybrydyzują.

Typowy TLS (koncepcyjnie):

1. Krok asymetryczny: tożsamość i materiał sesji.
2. Klucze symetryczne sesji na bulk traffic.

Key exchange (Diffie–Hellman, ECDHE w TLS) pozwala wyprowadzić wspólny sekret bez transmisji sekretu — forward secrecy w zaawansowanych stemach.

Pułapka: „Co szyfruje szybciej 10 GB backup?” → symetryczne. „Co dowodzi tożsamości serwera w HTTPS?” → certyfikat + asymetryczne, potem symetryczne bulk.

Hash, salt i stretching

Hash mapuje wejście na digest stałej długości; jednokierunkowy na egzaminie. Integralność i weryfikatory haseł.

Salt — unikalne losowe dane per rekord; łamie rainbow tables.

Key stretching / KDF — powtarzanie lub memory-hard praca; spowalnia offline guessing.

Podpisy cyfrowe: klucz prywatny podpisuje hash dokumentu; publiczny weryfikuje integralność i wiązanie z podpisującym — non-repudiation przy dobrym governance kluczy.

Obfuskacja vs szyfrowanie

Obfuskacja ukrywa sens bez silnych gwarancji krypto (encoding, proste XOR). Szyfrowanie zakłada rygorystyczną kontrolę kluczy. Egzamin może wspomnieć steganografię w obrazach/audio — tajność istnienia, nie tylko treści.

Nie wybieraj obfuskacji, gdy stem wymaga poufności regulacyjnej.

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

Pułapka: „Private key nigdy nie opuszcza hardware” → HSM lub TPM, nie .pem na share. „S3 z customer-managed keys” → KMS.

TPM ≠ HSM. TPM to platform-attached anchor; HSM to często appliance na enterprise signing.

Elementy PKI

PKI wiąże tożsamości z kluczami publicznymi przez certyfikaty podpisane przez CA.

• Klucz publiczny — dystrybuowany
• Klucz prywatny — ściśle chroniony; utrata = impersonation
• Certyfikat — oświadczenie CA: „ten klucz należy do subject”
• CSR — wniosek o certyfikację klucza publicznego
• Root of trust — anchor CA

Walidacja łańcucha:

Root CA (self-signed anchor)
  → Intermediate CA
    → Leaf (serwer lub użytkownik)

Awaria na dowolnym ogniwie → ostrzeżenia lub ciche zerwanie zaufania w API.

Unieważnienie: CRL vs OCSP

Pułapka: expired vs revoked — oba fail validation, ale naprawa inna (renew vs reissue). Zły hostname (CN/SAN) fail identity mimo ważnego łańcucha.

Wildcard i SAN

Wildcard (*.example.com) upraszcza admin, zwiększa blast radius przy wycieku klucza. SAN wymienia jawne nazwy; nowoczesna praktyka faworyzuje SAN-heavy.

Self-signed vs public CA

Self-signed wymaga ręcznej instalacji trust store — OK na lab/internal PKI; ryzyko przy uczeniu użytkowników klikania przez ostrzeżenia. Public CA dla open internet.

Key escrow

Escrow przechowuje klucze u trzeciej strony (recovery/compliance). Napięcie: pomaga przy utracie pracownika; zwiększa ryzyko dostępu insider/rządowego. Egzamin: tradeoff, nie „zawsze dobrze”.

Zakres szyfrowania: at rest, in transit, in use

FDE vs plik/wolumen vs field-level — stem wybiera wg granularności i apetytu na key mgmt. TDE bazy chroni media; szyfrowanie pól w aplikacji — droższe, drobniejsze.

Przykład: skradziony laptop

• FDE + TPM + PIN → at rest przy wyłączonym
• Screen lock + idle timeout → mniejsza ekspozycja in use
• Remote wipe → korekcyjna containment

TLS do chmury nie pomaga przy offline forensics bez FDE lub słabego hasła.

Blockchain (głębokość egzaminu)

SY0-701 oczekuje poziomu koncepcji: łańcuch bloków, hash łączący integralność, rozproszone kopie — nie produkcyjne smart contracty. Kąt: integralność i audit trail wielu stron.

Typowe pułapki krypto

1. „Encrypt password database” → salted hash.
2. Hash na poufność → hash nie ukrywa przed brute force guessów.
3. Symetryczne na tożsamość serwera WWW → certyfikaty (asymetryczne).
4. Ignorowanie revocation → klient musi sprawdzić CRL/OCSP.
5. Downgrade attacks — stare protokoły „dla kompatybilności”.
6. Ten sam klucz encrypt i sign — zła praktyka; egzamin sugeruje separację.

Porównanie: pytania audytorów

Jak ćwiczyć

1. Property drill: 10 assetów — przypisz CIA/non-repudiation i kontrolki.
2. Storyboard TLS: handshake; oznacz fazy sym./asym.
3. Break-the-chain: brak intermediate; obserwuj fail; napraw trust store.
4. Revocation: openssl ocsp lub devtools — status OCSP na live site.
5. Zakaz suchych fiszek: scenariusz → wybór → because.

Sukces krypto na Security+ to jakość decyzji, nie rozmiary bloków. Gdy legal pyta o PDF, odpowiadasz podpisami i hash, precyzujesz zakres TLS i wskazujesz HSM-backed signing przy sporze — dokładnie to, co nagradza SY0-701.