Kryptografia asymetryczna - klucz publiczny i prywatny w praktyce

Wysyłasz poufny plik, logujesz się do serwera albo podpisujesz dokument elektroniczny i chcesz wiedzieć, co naprawdę chroni dane? Klucz asymetryczny opisuje rozwiązanie oparte na parze kluczy publicznym i prywatnym, które pozwala szyfrować informacje, potwierdzać tożsamość oraz wykrywać późniejsze modyfikacje. Wyjaśniam, jak działa ten mechanizm, czym różni się od kryptografii symetrycznej, gdzie spotkasz go w praktyce i jak bezpiecznie używać go w Pythonie.

Na czym polega działanie pary kluczy

Kryptografia asymetryczna wykorzystuje dwa matematycznie powiązane klucze. Publiczny można przekazać innym osobom lub opublikować w certyfikacie. Prywatny przechowuje właściciel i używa go do odszyfrowywania wiadomości albo tworzenia podpisów.

Gdy chcę wysłać Ci poufny komunikat, szyfruję go Twoim kluczem publicznym. Odczytać go może tylko osoba posiadająca pasujący klucz prywatny. Odwrotny kierunek służy przede wszystkim do podpisu, a nie do prostego „szyfrowania prywatnym kluczem” w potocznym znaczeniu.

W uproszczeniu wygląda to tak:

1. Odbiorca generuje parę kluczy.
2. Udostępnia klucz publiczny.
3. Nadawca szyfruje dane kluczem publicznym odbiorcy.
4. Odbiorca odszyfrowuje je swoim kluczem prywatnym.

Sam fakt posiadania klucza publicznego nie daje dostępu do chronionych danych. Problem zaczyna się wtedy, gdy ktoś zdobędzie klucz prywatny albo podmieni publiczny klucz na własny. Dlatego kryptografia asymetryczna wymaga także uwierzytelniania kluczy, na przykład przez certyfikaty, odciski palców lub zaufany kanał dystrybucji.

Szyfrowanie i podpis cyfrowy to dwa różne zastosowania

Poufność wiadomości

Do szyfrowania używa się publicznego klucza osoby, która ma otrzymać dane. Prywatny klucz tej osoby służy później do odszyfrowania. To praktyczne rozwiązanie w poczcie elektronicznej, wymianie plików i komunikacji między systemami.

Nie szyfruję jednak dużych plików bezpośrednio metodą asymetryczną. Takie operacje są kosztowniejsze obliczeniowo, a algorytmy mają ograniczenia dotyczące długości wiadomości. W praktyce szyfruję dane szybkim algorytmem symetrycznym, a kluczem publicznym zabezpieczam tylko krótki klucz sesyjny.

Przeczytaj również: Atomic Design - Porządek w UI, szybszy rozwój produktu

Autentyczność i integralność

Podpis cyfrowy działa inaczej. Nadawca tworzy podpis przy użyciu klucza prywatnego, a odbiorca sprawdza go za pomocą odpowiadającego mu klucza publicznego. Jeśli plik zmienił się choćby o jeden znak, weryfikacja powinna się nie powieść.

Podpis nie musi ukrywać treści. Jego zadaniem jest wykazanie, że dane podpisał posiadacz określonego klucza oraz że nie zostały zmodyfikowane po podpisaniu. To mechanizm używany między innymi przy aktualizacjach oprogramowania, certyfikatach TLS, dokumentach elektronicznych i logowaniu do serwerów SSH.

Gdzie spotykamy kryptografię asymetryczną

Najbardziej znanym przykładem jest HTTPS. Przeglądarka korzysta z certyfikatu serwera, sprawdza jego wiarygodność, a podczas ustanawiania połączenia uzgadnia klucze potrzebne do dalszej, szybkiej komunikacji. Użytkownik widzi kłódkę w przeglądarce, ale pod spodem działa cały proces wymiany kluczy, uwierzytelniania i szyfrowania.

Drugim codziennym zastosowaniem jest SSH. Klient może rozpoznać serwer po jego kluczu publicznym, a użytkownik może uwierzytelnić się podpisem wykonanym własnym kluczem prywatnym. To bezpieczniejszy i wygodniejszy model niż wielokrotne wpisywanie hasła, pod warunkiem że plik z kluczem prywatnym jest dobrze chroniony.

Podobny mechanizm działa przy podpisywaniu paczek, kodu i aktualizacji. System nie musi ufać samemu plikowi. Sprawdza, czy podpis pasuje do znanego klucza autora. Jeżeli ktoś zmodyfikuje program po drodze, kontrola integralności wykryje problem.

W systemach firmowych klucze publiczne są często umieszczane w certyfikatach X.509. Certyfikat łączy klucz z tożsamością podmiotu, a urząd certyfikacji potwierdza tę relację. Bez tego odbiorca wie, że ma jakiś klucz, ale niekoniecznie wie, do kogo on należy.

RSA, ECC i wymiana kluczy

RSA to klasyczny algorytm oparty na trudności rozkładu dużych liczb na czynniki pierwsze. Nadal można go spotkać w certyfikatach i starszych systemach, ale dla nowych projektów nie wybieram go automatycznie. Przy nowych implementacjach trzeba dobrać rozmiar klucza, schemat paddingu i sposób przechowywania, a każdy z tych elementów wpływa na bezpieczeństwo.

ECC, czyli kryptografia krzywych eliptycznych, osiąga podobny poziom bezpieczeństwa przy krótszych kluczach. Zmniejsza to ilość danych przesyłanych w protokole i może ograniczyć koszty obliczeniowe. Popularne rozwiązania wykorzystują między innymi Curve25519 do uzgadniania sekretu oraz Ed25519 do podpisów.

Warto rozdzielić trzy pojęcia, które początkujący często wrzucają do jednego worka.

• Szyfrowanie kluczem publicznym chroni treść przed osobami postronnymi.
• Podpis cyfrowy potwierdza autora i wykrywa modyfikacje.
• Wymiana kluczy, na przykład za pomocą Diffiego-Hellmana, pozwala uzgodnić wspólny sekret bez przesyłania go wprost.

Najrozsądniejszy wybór zależy od protokołu i biblioteki, a nie od samej nazwy algorytmu. W nowych zastosowaniach RSA powinno korzystać z OAEP przy szyfrowaniu oraz PSS przy podpisach. Starsze schematy PKCS#1 v1.5 zostawia się głównie dla zgodności z istniejącymi systemami.

Dlaczego systemy łączą szyfrowanie asymetryczne i symetryczne

Kryptografia symetryczna używa tego samego sekretnego klucza do szyfrowania i odszyfrowywania. Jest bardzo szybka, dlatego nadaje się do dużych plików, baz danych i całych sesji komunikacyjnych. Jej słabym punktem pozostaje bezpieczne przekazanie wspólnego sekretu.

Mechanizm asymetryczny rozwiązuje właśnie ten problem, ale działa wolniej. W typowym połączeniu hybrydowym system generuje losowy klucz sesyjny, szyfruje nim właściwe dane, a potem zabezpiecza sam klucz sesyjny publicznym kluczem odbiorcy.

To połączenie jest fundamentem wielu protokołów internetowych. Z mojego doświadczenia wynika, że właśnie model hybrydowy najlepiej tłumaczy, dlaczego „szyfrowanie kluczem publicznym” nie oznacza, że cały film lub archiwum jest liczone bezpośrednio przez RSA.

Prosty przykład w Pythonie

Do nauki można wykorzystać bibliotekę cryptography. Poniższy przykład generuje parę RSA, szyfruje krótką wiadomość kluczem publicznym i odszyfrowuje ją kluczem prywatnym.

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding, rsa

private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=3072
)
public_key = private_key.public_key()

message = b"Tajna wiadomosc"

ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

assert plaintext == message

W przykładzie użyłem klucza o długości 3072 bitów oraz OAEP z SHA-256. To demonstracja mechanizmu, a nie gotowy system produkcyjny. W aplikacji trzeba jeszcze bezpiecznie zapisać klucz, kontrolować dostęp, obsłużyć rotację oraz ustalić, jak odbiorca zweryfikuje autentyczność klucza publicznego.

Przy podpisywaniu wiadomości schemat wygląda inaczej. Klucz prywatny tworzy podpis, a publiczny go sprawdza.

signature = private_key.sign(
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ),
    hashes.SHA256()
)

public_key.verify(
    signature,
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ),
    hashes.SHA256()
)

Nie implementowałbym RSA samodzielnie na podstawie wzorów z kursu. Biblioteka kryptograficzna rozwiązuje wiele trudnych problemów związanych z paddingiem, losowością i ochroną przed atakami bocznymi. Własny kod może być dobrym ćwiczeniem matematycznym, ale rzadko jest rozsądną podstawą realnego zabezpieczenia.

Najczęstsze błędy przy używaniu kluczy

Najpoważniejszy błąd polega na traktowaniu klucza prywatnego jak zwykłego pliku konfiguracyjnego. Nie powinien trafić do repozytorium, obrazu kontenera, logów ani wiadomości wysłanej komunikatorem. Jeżeli istnieje podejrzenie wycieku, klucz trzeba unieważnić i zastąpić nową parą, a nie tylko zmienić jego nazwę.

• Nie generuj kluczy z hasła, daty ani przewidywalnego ciągu znaków.
• Nie udostępniaj klucza prywatnego razem z publicznym.
• Nie szyfruj dużych danych bezpośrednio RSA.
• Nie wyłączaj weryfikacji certyfikatu TLS „na chwilę” na produkcji.
• Nie używaj przestarzałych algorytmów tylko dlatego, że są łatwe do znalezienia w przykładzie.
• Nie zakładaj, że podpis automatycznie zapewnia poufność.

W większych systemach klucze przechowuje się w menedżerach sekretów, modułach HSM albo usługach KMS. Takie rozwiązania zwiększają ochronę i ułatwiają rotację, ale dodają koszty, konfigurację oraz obowiązki administracyjne. Mały projekt może zacząć od zaszyfrowanego magazynu sekretów i ograniczonych uprawnień, lecz klucz prywatny nie powinien być wpisany na stałe w kodzie Pythona.

Trzeba też pamiętać o kopiach zapasowych. Utrata klucza prywatnego może oznaczać bezpowrotną utratę dostępu do zaszyfrowanych danych. Z drugiej strony kopia przechowywana bez ochrony tworzy drugie miejsce potencjalnego wycieku. Bezpieczna polityka kluczy obejmuje więc generowanie, dystrybucję, przechowywanie, rotację i wycofywanie starych kluczy.

Jak rozsądnie podejść do tego mechanizmu

Para kluczy publicznego i prywatnego nie jest magiczną tarczą. Chroni konkretny element procesu, ale nie naprawi przejętego konta, błędnej konfiguracji serwera ani złośliwego kodu uruchomionego już po odszyfrowaniu danych.

Najlepszy efekt daje połączenie kilku warstw. Używam sprawdzonej biblioteki, aktualnych algorytmów, certyfikatów lub innych metod weryfikacji tożsamości, ograniczonych uprawnień oraz regularnej rotacji. W przypadku Pythona szczególnie ważne jest, by sekretów nie trzymać w plikach dostępnych przez system kontroli wersji.

Jeżeli zapamiętasz jedną zasadę, niech będzie nią ta. Publiczny klucz służy do udostępniania, prywatny do ochrony. Cała wartość kryptografii asymetrycznej zależy od tego, czy ten drugi rzeczywiście pozostaje tajny, a odbiorca potrafi upewnić się, że otrzymał właściwy klucz publiczny.