Początki kryptografii asymetrycznej: jak protokół Diffie-Hellman i RSA zmieniły bezpieczeństwo sieci

Od jakiego problemu zaczęła się rewolucja bezpieczeństwa sieci?

Dlaczego samo szyfrowanie nie wystarczało?

Jeżeli dwie osoby chcą przesłać sobie tajną wiadomość, intuicyjnie mogą użyć szyfru: nadawca szyfruje tekst, odbiorca go odszyfrowuje. Przez stulecia taki model opierał się na jednym wspólnym sekretnym kluczu. Ten sam klucz służył do szyfrowania i odszyfrowywania albo był z nimi ściśle powiązany. To fundament kryptografii symetrycznej.

Model jest wydajny i nadal pozostaje niezwykle ważny. Algorytmy symetryczne, takie jak AES, dobrze nadają się do szyfrowania dużych ilości danych. Pojawia się jednak pytanie decyzyjne, które długo ograniczało rozwój bezpiecznych sieci: jak przekazać wspólny sekret osobie, z którą nie ma jeszcze bezpiecznego kanału komunikacji?

W małej organizacji można było przekazać klucz osobiście, przez zaufanego kuriera lub wykorzystać wcześniej uzgodnione hasło. W globalnej sieci takie rozwiązanie przestaje być praktyczne. Sklep internetowy nie może wysłać osobnego tajnego klucza każdemu odwiedzającemu. Bank nie może zakładać, że każdy klient spotka się wcześniej z pracownikiem, aby wymienić materiał kryptograficzny. ^[1]

Problem dystrybucji klucza w skali sieci

To właśnie problem dystrybucji klucza był główną barierą. Gdy system z kryptografią symetryczną obsługuje wiele niezależnych stron, liczba relacji zaufania szybko rośnie. Jeżeli każda para uczestników potrzebuje odrębnego sekretu, zarządzanie kluczami staje się logistycznie trudne, kosztowne i podatne na błędy.

Wyobraźmy sobie sieć firm, w której każdy dział musi wymieniać zaszyfrowane dokumenty z pozostałymi działami. Używanie jednego wspólnego hasła dla wszystkich byłoby wygodne, ale katastrofalne dla bezpieczeństwa: odejście jednej osoby, wyciek jednego urządzenia albo przejęcie jednego konta naraża całą sieć. Tworzenie osobnych sekretów dla każdej relacji poprawia izolację, ale komplikuje administrację.

Bezpieczna komunikacja potrzebowała mechanizmu, który pozwoliłby ustanowić sekret przez niezaufaną sieć, bez wcześniejszego osobistego kontaktu. Odpowiedzią okazała się kryptografia asymetryczna oraz mechanizmy wymiany kluczy.

Trzy pytania, które zmieniły architekturę protokołów

Początki kryptografii asymetrycznej można dobrze zrozumieć przez trzy praktyczne pytania:

• Jak dwie strony mogą uzgodnić tajny klucz, gdy ich komunikację może obserwować osoba trzecia?
• Jak opublikować informację przydatną do szyfrowania, nie ujawniając zarazem informacji potrzebnej do odszyfrowania?
• Jak rozpoznać, czy publiczny klucz rzeczywiście należy do banku, serwera, partnera biznesowego albo innego oczekiwanego podmiotu?

Diffie-Hellman rozwiązał przede wszystkim pierwszy problem, czyli bezpieczną wymianę kluczy. RSA pokazał zaś, jak para kluczy publiczny–prywatny może służyć do szyfrowania i podpisów cyfrowych. Oba pomysły otworzyły drogę do protokołów, na których zbudowano później bezpieczny internet, lecz ich historia to także katalog błędów, których nie wolno powtarzać.

Błąd pierwszy: traktowanie Diffiego-Hellmana jak algorytmu szyfrującego dane

Co naprawdę robi protokół Diffie-Hellman?

Protokół Diffie-Hellman, opisany publicznie przez Whitfielda Diffiego i Martina Hellmana w 1976 roku, nie szyfruje bezpośrednio wiadomości użytkownika. Jego podstawową funkcją jest umożliwienie dwóm stronom wyprowadzenia wspólnego sekretu mimo tego, że wymieniają wiadomości przez kanał dostępny dla obserwatora. ^[3]

Klasyczny opis wykorzystuje arytmetykę modularną. Strony uzgadniają publiczne parametry matematyczne, zwykle oznaczane jako p i g. Następnie każda z nich losuje własną tajną wartość. Z tej tajnej wartości i parametrów publicznych oblicza informację, którą może przesłać otwartym kanałem. Odbiorca wykonuje analogiczne działanie. Obie strony dochodzą do identycznego sekretu, ale obserwator widzący całą wymianę nie powinien umieć go praktycznie odtworzyć.

Bezpieczeństwo klasycznego Diffiego-Hellmana opiera się na trudności obliczeniowej problemu logarytmu dyskretnego w odpowiednio dobranej grupie matematycznej. Najważniejsza intuicja jest prosta: łatwo obliczyć wartość publiczną na podstawie sekretu, lecz bardzo trudno odwrócić ten proces i odzyskać sekret z samej wartości publicznej.

Dlaczego wspólny sekret nie jest jeszcze kluczem do AES?

Częsty błąd implementacyjny polega na potraktowaniu wyniku Diffiego-Hellmana jako gotowego klucza szyfrującego. W poprawnie zaprojektowanych protokołach surowy sekret zwykle przechodzi przez funkcję wyprowadzania klucza (KDF, Key Derivation Function). Taka funkcja przekształca materiał wejściowy w osobne klucze o wymaganej długości i przeznaczeniu.

Jedna sesja może potrzebować kilku niezależnych wartości: klucza do szyfrowania danych wysyłanych przez klienta, innego klucza dla danych wysyłanych przez serwer, kluczy do uwierzytelniania oraz wartości pomocniczych. Używanie jednego materiału kryptograficznego do kilku zadań łamie zasadę separacji kluczy. W razie problemu w jednym mechanizmie skutki mogą przejść na pozostałe.

Bezpieczny wzorzec jest zatem hybrydowy: Diffie-Hellman ustanawia wspólny sekret, KDF tworzy klucze sesyjne, a szybki szyfr symetryczny chroni właściwy ruch sieciowy. Taki schemat łączy wygodę kryptografii asymetrycznej z wydajnością kryptografii symetrycznej.

Wymiana kluczy a poufność rozmowy

Sam fakt, że dwie strony wyliczyły wspólny sekret, nie daje jeszcze pełnej gwarancji poufności. Trzeba ustalić, z kim naprawdę odbyła się wymiana. Jeśli atakujący potrafi wejść pomiędzy komunikujące się strony, może wykonać niezależną wymianę Diffie-Hellmana z każdą z nich.

Klient będzie wtedy dzielił jeden sekret z atakującym, a serwer drugi sekret z atakującym. Napastnik może odszyfrowywać, modyfikować i ponownie szyfrować komunikację. Obie strony będą miały wrażenie, że rozmawiają ze sobą bezpośrednio. To klasyczny atak man-in-the-middle (MITM, atak pośrednika).

Wniosek praktyczny jest ważny: Diffie-Hellman zapewnia uzgodnienie sekretu, ale bez dodatkowego mechanizmu nie uwierzytelnia drugiej strony. Do ochrony przed MITM potrzebne są podpisy cyfrowe, certyfikaty, wcześniej zweryfikowane odciski kluczy lub inne źródło zaufania.

Błąd drugi: ignorowanie różnicy między zwykłym DH a efemerycznym ECDHE

Dlaczego długoterminowy sekret zwiększa ryzyko?

W pierwotnych konstrukcjach można było używać stałych wartości prywatnych Diffie-Hellmana. Rozwiązanie wydaje się wygodne: strona tworzy sekret raz i wykorzystuje go w wielu połączeniach. Taka wygoda ma jednak wysoką cenę. Jeżeli długoterminowy sekret zostanie później ujawniony, zapisane wcześniej sesje mogą być zagrożone, o ile napastnik przechwycił dane potrzebne do ich odtworzenia.

W bezpieczeństwie sieci szczególnie istotna stała się właściwość nazywana utajnieniem przekazywanym albo forward secrecy. Oznacza ona, że kompromitacja długoterminowego klucza serwera nie powinna automatycznie odsłaniać treści dawnych sesji. To ogranicza skutki incydentu: kradzież jednego klucza nie powinna otwierać całego archiwum przechwyconej komunikacji.

Osiąga się to przez używanie jednorazowych lub krótkotrwałych wartości prywatnych dla każdej sesji. Takie podejście nazywa się efemerycznym Diffie-Hellmanem, a w nowoczesnych protokołach często stosuje się jego wariant oparty na krzywych eliptycznych, czyli ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

Warto przeczytać również powiązany artykuł: Historia algorytmu Backpropagation: od teorii do globalnej skali.

Co zmieniły krzywe eliptyczne?

Klasyczny Diffie-Hellman działa w grupach modularnych i może wymagać dużych parametrów, aby zapewniać oczekiwany poziom bezpieczeństwa. Kryptografia krzywych eliptycznych stosuje inne struktury matematyczne. Jej praktyczną zaletą jest możliwość uzyskania silnego bezpieczeństwa przy krótszych kluczach i mniejszych danych przesyłanych podczas uzgadniania. ^[4]

Nie oznacza to, że „krótszy klucz zawsze jest lepszy”. Porównywanie długości kluczy między różnymi rodzinami algorytmów bez kontekstu jest błędem. Klucz RSA i klucz używany w ECDH działają na innych zasadach matematycznych, dlatego sama liczba bitów nie opisuje wprost tego samego poziomu odporności.

W praktyce współczesne implementacje TLS wykorzystują sprawdzone grupy i krzywe, a administrator nie powinien samodzielnie tworzyć parametrów kryptograficznych „dla większej oryginalności”. Własne parametry bez silnego uzasadnienia i audytu to ryzyko, a nie przewaga.

Jak rozpoznać błędną konfigurację?

Niebezpieczne symptomy są dość konkretne. Problemem może być możliwość negocjowania przestarzałych pakietów kryptograficznych, używanie statycznej wymiany kluczy, tolerowanie słabych grup Diffie-Hellmana albo utrzymywanie nieaktualnej wersji biblioteki kryptograficznej. Z perspektywy użytkownika objawy bywają niewidoczne, ponieważ połączenie nadal pokazuje ikonę kłódki.

Ikona kłódki w przeglądarce oznacza przede wszystkim, że połączenie używa HTTPS i że przeglądarka zaakceptowała certyfikat dla danej witryny. Nie jest kompletnym raportem bezpieczeństwa aplikacji. Nie mówi na przykład, czy serwer ma błędy autoryzacji, czy formularz nie zapisuje haseł w niebezpieczny sposób albo czy dane po odszyfrowaniu są właściwie chronione.

Tip: w systemach produkcyjnych konfigurację TLS należy utrzymywać zgodnie z zaleceniami aktualnej dokumentacji używanego serwera, systemu operacyjnego i biblioteki kryptograficznej. Ręczne wybieranie algorytmów na podstawie starych poradników często prowadzi do pozostawienia niepotrzebnej kompatybilności z przeszłością.

Błąd trzeci: przekonanie, że RSA oznacza wyłącznie szyfrowanie

Na czym polega pomysł RSA?

Algorytm RSA, zaprezentowany publicznie w 1977 roku przez Rona Rivesta, Adiego Shamira i Leonarda Adlemana, stał się najbardziej rozpoznawalnym symbolem kryptografii klucza publicznego. Jego konstrukcja wykorzystuje parę kluczy: publiczny, który można rozpowszechniać, oraz prywatny, który musi pozostać tajny.

W uproszczonym obrazie osoba chcąca przesłać tajną wiadomość szyfruje ją kluczem publicznym odbiorcy, a odszyfrować może ją tylko posiadacz odpowiadającego klucza prywatnego. Matematycznym fundamentem RSA jest trudność faktoryzacji dużych liczb złożonych, czyli rozkładu ich na czynniki pierwsze.

To przełomowe, ponieważ pozwoliło publikować dane kryptograficzne bez publikowania pełnego sekretu. Serwer mógł udostępniać klucz publiczny tysiącom albo milionom użytkowników, a klucz prywatny zachować w kontrolowanym środowisku. W ten sposób kryptografia asymetryczna radykalnie zmieniła model zaufania w sieci.

Szyfrowanie i podpis cyfrowy to dwa różne zastosowania

RSA może służyć zarówno do ochrony poufności, jak i do potwierdzania autentyczności danych, lecz tych zastosowań nie należy mieszać. Szyfrowanie odpowiada na pytanie: „kto może odczytać wiadomość?”. Podpis cyfrowy odpowiada na inne pytania: „kto przygotował tę wiadomość?” oraz „czy nie została zmieniona po podpisaniu?”.

W schemacie podpisu RSA nadawca nie „szyfruje całego dokumentu kluczem prywatnym”. To popularny skrót myślowy, który łatwo prowadzi do złych implementacji. Poprawny proces obejmuje zwykle następujące kroki:

1. z danych obliczana jest funkcja skrótu, na przykład SHA-256;
2. skrót jest kodowany zgodnie z bezpiecznym schematem podpisu;
3. powstała wartość zostaje podpisana kluczem prywatnym nadawcy;
4. odbiorca weryfikuje podpis za pomocą klucza publicznego oraz samodzielnie obliczonego skrótu danych.

Jeżeli choć jeden bit podpisanej wiadomości zostanie zmieniony, jej skrót przestanie odpowiadać podpisowi. Odbiorca powinien wtedy odrzucić dane jako zmodyfikowane albo nieprawidłowo podpisane.

Dlaczego „podpisanie prywatnym kluczem” nie wystarcza?

RSA jest mechanizmem matematycznym, ale bezpieczne użycie wymaga właściwego schematu kodowania i sprawdzania danych wejściowych. Historycznie stosowano między innymi PKCS#1 v1.5, natomiast współczesne systemy powinny preferować bezpieczniejsze schematy, takie jak RSA-PSS dla podpisów. W przypadku szyfrowania właściwym wyborem jest zwykle RSA-OAEP, a nie własny format danych przygotowany przez aplikację.

Nie należy implementować RSA przez samodzielne wykonywanie operacji matematycznych na liczbach. Podejście typu „weźmiemy tekst, zamienimy go na liczbę i podniesiemy do potęgi” pomija zabezpieczenia konieczne przeciw znanym klasom ataków. Dobra biblioteka kryptograficzna powinna dostarczać gotowe, wysokopoziomowe funkcje podpisu i weryfikacji.

W praktyce podpis cyfrowy RSA może chronić aktualizację programu, dokument firmowy, komunikat API albo element procesu logowania. Sama poprawność podpisu nie mówi jednak jeszcze, czyj klucz publiczny został użyty. Do tego potrzebny jest mechanizm wiązania klucza z konkretną tożsamością. ^[2]

Błąd czwarty: uznanie klucza publicznego za automatyczny dowód tożsamości

Dlaczego publiczny klucz bez kontekstu nie rozwiązuje problemu zaufania?

Każdy może wygenerować parę kluczy i opublikować jej część publiczną. Z tego powodu sam klucz publiczny nie dowodzi, że należy do wskazanego banku, sklepu czy serwera firmowego. Atakujący może stworzyć własny klucz, opisać go nazwą znanej marki i próbować przekonać użytkownika, aby mu zaufał.

To szczególnie ważne w sieci, gdzie użytkownik zwykle nie zna wcześniej odcisku prawdziwego klucza serwera. Przeglądarka musi otrzymać wiarygodną odpowiedź na pytanie: „czy ten klucz publiczny rzeczywiście należy do właściciela domeny, z którą próbuję się połączyć?”.

Warto przeczytać również powiązany artykuł: Unix: system, który ukształtował DevOps i chmurę.

Rozwiązaniem stały się certyfikaty cyfrowe oraz infrastruktura klucza publicznego, określana skrótem PKI (Public Key Infrastructure).

Co zawiera certyfikat?

Certyfikat TLS wiąże klucz publiczny z określoną tożsamością, najczęściej nazwą domenową. Zawiera między innymi klucz publiczny podmiotu, nazwy domen, okres ważności, informacje o wystawcy oraz podpis cyfrowy urzędu certyfikacji.

Gdy użytkownik odwiedza witrynę HTTPS, serwer przedstawia certyfikat. Przeglądarka sprawdza, czy:

• certyfikat obejmuje nazwę odwiedzanej domeny;
• nie minął jego okres ważności;
• łańcuch podpisów prowadzi do zaufanego urzędu certyfikacji;
• certyfikat nie został unieważniony lub oznaczony jako niewiarygodny w dostępnych mechanizmach kontroli;
• serwer potrafi udowodnić posiadanie klucza prywatnego odpowiadającego kluczowi publicznemu z certyfikatu.

To ostatnie sprawdzenie ma zasadnicze znaczenie. Samo przesłanie cudzego certyfikatu nie daje atakującemu pełnej możliwości podszycia się pod serwer, jeżeli nie posiada on odpowiadającego mu klucza prywatnego.

Łańcuch zaufania nie jest magią

Urząd certyfikacji, czyli CA (Certificate Authority), podpisuje certyfikaty po wykonaniu określonej walidacji. Przeglądarki i systemy operacyjne mają listy zaufanych głównych urzędów certyfikacji. Certyfikat serwera jest często podpisany nie bezpośrednio przez urząd główny, lecz przez urząd pośredni. W ten sposób powstaje łańcuch zaufania.

Model ten jest praktyczny, ale nie zwalnia z kontroli. Błędy mogą dotyczyć nie tylko algorytmów, lecz także procesu: niewłaściwie wydanego certyfikatu, źle chronionego klucza prywatnego, braku odnowienia certyfikatu albo podłączenia w aplikacji własnego mechanizmu, który ignoruje błędy walidacji.

Krótki przykład: aplikacja mobilna może mieć poprawnie wdrożone TLS, ale programista podczas testów doda wyjątek akceptujący każdy certyfikat. Jeśli taki kod trafi do wersji produkcyjnej, atakujący w obcej sieci Wi-Fi może przedstawić dowolny certyfikat i przechwycić połączenie. Silna kryptografia po stronie serwera nie naprawi klienta, który świadomie wyłącza weryfikację.

Błąd piąty: wyłączanie walidacji certyfikatów „tylko na chwilę”

Jak rozpoznać niebezpieczny wyjątek?

Alarmujące są fragmenty kodu lub ustawienia opisane jako „trust all certificates”, „accept any hostname”, „ignore SSL errors” albo „disable certificate verification”. Czasem pojawiają się, aby obejść problem z certyfikatem testowym, serwerem wewnętrznym lub niepoprawnie skonfigurowaną nazwą domenową.

Skutek jest prosty: klient przestaje odróżniać prawdziwy serwer od pośrednika. W takim układzie nawet poprawnie użyte ECDHE i podpisy RSA nie zapewniają oczekiwanego uwierzytelnienia, ponieważ aplikacja zgadza się na dowolną tożsamość.

Co zrobić lepiej?

Środowiska testowe również powinny korzystać z poprawnych certyfikatów i właściwej walidacji nazwy hosta. Można użyć wewnętrznego urzędu certyfikacji, dodać jego certyfikat główny do zaufanego magazynu testowego albo korzystać z automatycznego wydawania certyfikatów dla publicznie dostępnych domen.

Jeżeli organizacja stosuje przypinanie klucza lub certyfikatu (certificate pinning), powinna przygotować procedurę rotacji. Przypięcie starego pojedynczego klucza bez zapasowego planu może unieruchomić aplikację po planowanej zmianie certyfikatu albo po incydencie wymagającym natychmiastowej wymiany kluczy.

Błąd szósty: używanie RSA do zadań, dla których nie jest już właściwym wyborem

Dlaczego RSA nie powinno dziś transportować klucza sesyjnego w TLS?

W starszych wersjach TLS klient mógł wygenerować sekret sesyjny, zaszyfrować go kluczem publicznym RSA serwera i przesłać do serwera. Rozwiązanie było funkcjonalne, ale miało istotne ograniczenie: późniejsza kompromitacja klucza prywatnego RSA mogła umożliwić odszyfrowanie wcześniej zapisanych połączeń, jeśli napastnik przechwycił ich ruch.

Dlatego współczesne konfiguracje TLS powinny używać efemerycznej wymiany kluczy, zwykle ECDHE, do ustanowienia sekretu sesyjnego. RSA nadal może występować w certyfikacie i służyć serwerowi do złożenia podpisu uwierzytelniającego wymianę, lecz nie musi szyfrować materiału sesyjnego.

To praktyczne rozróżnienie porządkuje role:

• ECDHE pomaga ustanowić świeży sekret sesji;
• KDF wyprowadza z niego klucze robocze;
• szyfr symetryczny AEAD chroni właściwe dane przesyłane w sesji;
• RSA lub algorytm oparty na krzywych eliptycznych może służyć do podpisu i uwierzytelnienia serwera.

Porównanie zastosowań Diffie-Hellmana i RSA

Błąd siódmy: tworzenie własnego schematu kryptograficznego

Dlaczego poprawne elementy nie gwarantują poprawnego systemu?

Można użyć silnego RSA, nowoczesnej krzywej dla ECDHE i bezpiecznej funkcji skrótu, a mimo to zbudować podatny system. Problemy zwykle pojawiają się na styku mechanizmów: przy nieprawidłowej walidacji wejścia, ponownym używaniu losowości, braku separacji kluczy, błędnej obsłudze wyjątków albo niejasnym formacie komunikatów.

Przykładowo aplikacja może poprawnie weryfikować podpis, ale dopiero po wykonaniu niebezpiecznej operacji na danych otrzymanych od użytkownika. Może też podpisywać samą treść polecenia, ale pomijać identyfikator odbiorcy lub czas wygaśnięcia. Wtedy poprawny podpis da się wykorzystać poza pierwotnym kontekstem.

Lepsze rozwiązanie: korzystanie z kompletnych protokołów

Bezpieczniej jest używać dojrzałych protokołów i bibliotek niż projektować własny format wymiany danych. Dla komunikacji sieciowej naturalnym wyborem jest aktualnie wspierana wersja TLS. Dla podpisów należy korzystać z API, które jawnie wybiera schemat, na przykład RSA-PSS z SHA-256, zamiast udostępniać niskopoziomowe operacje RSA.

Równie istotne jest zarządzanie kluczami. Klucz prywatny serwera nie powinien trafiać do repozytorium kodu, obrazu kontenera ani pliku wysyłanego pocztą. W zależności od ryzyka może być chroniony przez kontrolę dostępu systemu, wydzielony magazyn sekretów albo moduł HSM. Należy także planować jego rotację, kopie zapasowe i reakcję na podejrzenie kompromitacji.

Co sprawdzić przed decyzją o użyciu RSA lub Diffie-Hellmana?

• Czy problem dotyczy uzgodnienia sekretu, szyfrowania, podpisu, czy uwierzytelnienia tożsamości?
• Czy używany protokół zapewnia uwierzytelnienie wymiany kluczy, a nie tylko samą wymianę?
• Czy konfiguracja TLS korzysta z aktualnych wersji protokołu i efemerycznej wymiany kluczy?
• Czy RSA jest używane z właściwym schematem, takim jak RSA-PSS dla podpisów albo RSA-OAEP dla szyfrowania?

Najważniejsze wnioski

• Kryptografia asymetryczna powstała jako odpowiedź na problem bezpiecznej dystrybucji kluczy w dużych sieciach.
• Diffie-Hellman służy przede wszystkim do uzgadniania wspólnego sekretu, a nie do bezpośredniego szyfrowania dużych ilości danych.
• Wspólny sekret z Diffie-Hellmana powinien zostać przekształcony przez funkcję KDF w odpowiednie klucze sesyjne.
• Sam Diffie-Hellman nie uwierzytelnia drugiej strony, dlatego potrzebne są między innymi certyfikaty lub podpisy cyfrowe chroniące przed atakiem MITM.
• Efemeryczny Diffie-Hellman, w tym ECDHE, pomaga zapewnić utajnienie przekazywane i ograniczyć skutki ujawnienia długoterminowego klucza.
• Bezpieczeństwo połączenia zależy nie tylko od algorytmu, lecz także od konfiguracji TLS, aktualności bibliotek i właściwego zarządzania kluczami.

Źródła

• [1] Carnegie Mellon University / IEEE – New Directions in Cryptography ↑
• [2] MIT / Communications of the ACM – A Method for Obtaining Digital Signatures and Public-Key Cryptosystems ↑
• [3] Computer History Museum – Whitfield Diffie ↑
• [4] Stanford University School of Engineering – Martin Hellman ↑