Skąd wzięła się kryptografia publiczna i jak trafiła do SSL oraz dzisiejszego HTTPS

Od szyfrów klasycznych do potrzeby kryptografii publicznej

Od szyfru Cezara do Enigmy – krótki szkic tła

Kryptografia towarzyszy komunikacji niemal od zawsze, ale przez większość historii opierała się na bardzo prostym założeniu: nadawca i odbiorca muszą wcześniej uzgodnić wspólny sekret. W świecie papieru i gońców taki model był wystarczający, choć często zawodny organizacyjnie.

Najprostsze systemy, jak szyfr Cezara, polegały na przesunięciu liter alfabetu o określoną liczbę pozycji. Sekret stanowiła liczba przesunięcia, którą strony musiały znać wcześniej. Z czasem pojawiały się bardziej złożone rozwiązania, np. szyfr Vigenère’a oparty na słowach-kluczach, ale zasada pozostała ta sama: jeden klucz, znany obu stronom.

W XX wieku kryptografia stała się nauką strategiczną. Maszyna Enigma używana przez Niemcy w czasie II wojny światowej była zaawansowanym systemem szyfrującym jak na realia epoki. Mimo to wciąż opierała się na kluczu symetrycznym: operatorzy musieli znać dzienne ustawienia rotora i tablic wtyczek. Po stronie aliantów powstały specjalistyczne ośrodki (Bletchley Park), które budowały elektromechaniczne maszyny do łamania Enigmy, a kryptografia na dobre stała się domeną matematyków i inżynierów.

Po wojnie, w czasie zimnej wojny, kryptografia była traktowana jak narzędzie wywiadu i wojska. Rozwiązania pozostawały tajne, a badania często prowadzone w ośrodkach rządowych. Model wciąż jednak pozostawał symetryczny – komunikujące się strony wymieniały klucze kanałami dyplomatycznymi, kurierskimi, czasem nawet fizycznie na nośnikach.

Cechy i ograniczenia kryptografii symetrycznej

Kryptografia symetryczna polega na użyciu tego samego klucza do szyfrowania i deszyfrowania. Klucz jest tajny, a bezpieczeństwo systemu zależy od tego, czy uda się go utrzymać w sekrecie. Przykładami współczesnych szyfrów symetrycznych są DES (historycznie) czy AES.

Ten model ma kilka silnych stron:

• jest bardzo szybki – umożliwia szyfrowanie dużych ilości danych przy niskim narzucie obliczeniowym,
• dobrze nadaje się do zabezpieczania danych „w spoczynku” (np. dysków),
• jest stosunkowo prosty do implementacji i analizy.

Jednocześnie generuje poważne problemy organizacyjne. Największy z nich to dystrybucja klucza. Jeśli dwie strony chcą ze sobą rozmawiać, muszą bezpiecznie uzgodnić wspólny sekret. Jeśli zrobią to kanałem niezaszyfrowanym, przeciwnik może podsłuchać. Jeśli zrobią to szyfrowanym – muszą już mieć jakiś wcześniejszy klucz, co tworzy błędne koło.

Drugi problem to skalowanie liczby kluczy. W sieci złożonej z wielu uczestników, w której każda para chce być w stanie rozmawiać prywatnie, liczba potrzebnych kluczy rośnie bardzo szybko. Dla N użytkowników trzeba utrzymywać około N(N−1)/2 różnych kluczy. Dla kilku osób to nie jest wyzwanie, ale dla banków, firm czy państwowej infrastruktury już tak.

Sieci komputerowe lat 60. i 70. – nowy świat problemów

W latach 60. i 70. pojawił się zupełnie inny kontekst: sieci komputerowe. ARPANET, prekursor Internetu, łączył odległe ośrodki badawcze i uniwersytety. Pojawiło się zdalne logowanie (telnet), przesyłanie plików (FTP), pierwsze maile.

W tym środowisku przestaje wystarczać model, w którym kilka ściśle powiązanych organizacji wymienia się kluczami symetrycznymi przy użyciu kurierów. Liczba potencjalnych połączeń rośnie, uczestnicy nie zawsze się znają, a topologia sieci staje się coraz bardziej dynamiczna. Gdy zaczęto myśleć o komercyjnym wykorzystaniu sieci – transmisji danych firmowych, późniejszym handlu elektronicznym – problem stał się palący.

Komputer na drugim końcu kontynentu może chcieć bezpiecznie porozmawiać z innym komputerem, z którym nigdy wcześniej nie wymienił klucza. Nie ma możliwości rozsyłania papierowych kluczy do wszystkich możliwych par w skali globalnej. Dotychczasowy model kryptografii symetrycznej zwyczajnie nie pasował do rodzącej się rzeczywistości rozproszonych sieci.

Dlaczego cyfrowy handel i masowa komunikacja ujawniły granice symetrii

Wraz z rozwojem infrastruktury sieciowej zaczęto przewidywać takie zastosowania jak:

• zdalny dostęp do kont bankowych,
• transakcje kartami płatniczymi przez sieć,
• przesyłanie dokumentów prawnych i kontraktów,
• komunikację biznesową z nieznanymi wcześniej kontrahentami.

W każdym z tych scenariuszy pojawia się nie tylko potrzeba poufności, ale także uwierzytelnienia: jak stwierdzić, że po drugiej stronie jest faktycznie bank, sklep lub partner biznesowy, a nie podszywający się atakujący. W modelu symetrycznym można się uwierzytelniać, udowadniając, że zna się sekret, ale wymaga to wcześniejszego uzgodnienia tego sekretu. Dla masowego, globalnego środowiska to ślepa uliczka.

Rozpoczęło się poszukiwanie rozwiązania, które pozwoliłoby dwóm stronom:

• utworzyć bezpieczny kanał bez wcześniejszej wymiany tajnego klucza,
• zapewnić poufność i uwierzytelnienie,
• działać w skali globalnej i z setkami tysięcy nieznanych wcześniej podmiotów.

Te właśnie potrzeby doprowadziły do powstania kryptografii z kluczem publicznym, która później stała się podstawą protokołów SSL/TLS i dzisiejszego HTTPS.

Narodziny kryptografii z kluczem publicznym – przełom Diffiego i Hellmana

Otwarte pytanie: szyfrowanie bez wspólnego sekretu

W latach 70. w środowisku naukowym krążyło pytanie, które dla praktyków wydawało się niemal paradoksem: czy da się zaszyfrować wiadomość do kogoś, z kim nigdy nie wymieniono tajnego klucza? Matematycy i badacze kryptografii zastanawiali się, czy można rozdzielić funkcję szyfrowania i deszyfrowania tak, aby każdy mógł znać jeden „połowiczny” element, a tylko właściciel drugiego posiadał władzę odszyfrowania.

Whitfield Diffie, zafascynowany problemem prywatności komunikacji, współpracował z Martinem Hellmanem z Uniwersytetu Stanforda. Ich prace zebrały wcześniejsze luźne pomysły i intuicje, ale przekształciły je w spójny model kryptografii z kluczem publicznym.

„New Directions in Cryptography” – co właściwie zaproponowano

W 1976 roku Diffie i Hellman opublikowali przełomowy artykuł „New Directions in Cryptography”. Dokument ten położył fundamenty pod całą kryptografię asymetryczną i zdefiniował kilka kluczowych idei:

• pojęcie klucza publicznego – informacji, którą można bez obaw rozpowszechniać,
• pojęcie klucza prywatnego – informacji, którą zna tylko właściciel,
• model, w którym szyfrowanie odbywa się kluczem publicznym, a deszyfrowanie kluczem prywatnym,
• zarys podpisu cyfrowego – operacji „odwrotnej”, gdzie to prywatny klucz generuje podpis, a publiczny weryfikuje.

Artykuł nie zawierał jeszcze kompletnego, praktycznego algorytmu szyfrującego z kluczem publicznym. Mimo to przełomem był już sam model myślowy. Po raz pierwszy jasno sformułowano koncepcje, które pozwalały rozdzielić funkcje szyfrowania i deszyfrowania, otwierając drogę do praktycznych implementacji.

Klucz publiczny i prywatny – właściwości, które zmieniły reguły gry

Kryptografia asymetryczna wprowadza zestaw wymagań, które muszą spełniać klucz publiczny i prywatny w bezpiecznym systemie:

• z klucza publicznego nie da się w praktyce obliczyć klucza prywatnego,
• wiadomość zaszyfrowana kluczem publicznym może być odszyfrowana wyłącznie odpowiadającym mu kluczem prywatnym,
• podpis cyfrowy utworzony kluczem prywatnym można zweryfikować kluczem publicznym, co daje niezaprzeczalność – autor nie może wiarygodnie zaprzeczyć, że podpisał daną wiadomość.

Taki model natychmiast sugeruje zastosowania, które dzisiaj są oczywiste w kontekście HTTPS: serwer WWW publikuje swój certyfikat z kluczem publicznym, klient szyfruje do niego informacje, a tylko serwer mający klucz prywatny może je odszyfrować. Jednocześnie to, że serwer potrafi udowodnić posiadanie klucza prywatnego związanego z certyfikatem, służy do jego uwierzytelnienia.

Protokół wymiany klucza Diffie-Hellmana

Najbardziej praktycznym elementem pracy Diffiego i Hellmana był protokół wymiany klucza, dziś znany jako Diffie-Hellman (DH). Choć sam w sobie nie zapewnia uwierzytelnienia, rozwiązuje fundamentalny problem: jak dwie strony mogą uzgodnić wspólny, losowy sekret przez publiczny kanał, zakładając, że przeciwnik wszystkie wiadomości podsłuchuje.

W wersji uproszczonej:

1. Strony uzgadniają publiczne parametry matematyczne (np. duże liczby pierwsze i generator w pewnej grupie).
2. Każda strona losuje swój sekret (liczbę) i na jego podstawie wylicza wartość, którą wysyła drugiej stronie.
3. Po wymianie tych wartości każda ze stron, korzystając z własnego sekretu oraz otrzymanej wartości, oblicza ten sam wspólny klucz.
4. Podsłuchujący widzi jedynie parametry publiczne i wartości wymienione, ale nie zna tajnych liczb, więc nie jest w stanie (w rozsądnym czasie) obliczyć wspólnego klucza.

Technicznie rzecz biorąc, bezpieczeństwo opiera się na trudności rozwiązania problemu logarytmu dyskretnego w odpowiednio dobranych grupach matematycznych. W praktyce ten protokół stał się jednym z filarów budowy bezpiecznych kanałów w SSL/TLS, szczególnie w nowocześniejszych wariantach (np. ECDHE).

Reakcje świata nauki i służb wywiadowczych

Publikacja „New Directions in Cryptography” była szokiem dla części środowiska. Dla cywilnych badaczy był to genialny przełom teoretyczny. Dla służb wywiadowczych – wyraźny sygnał, że mocna kryptografia może stać się powszechnie dostępna, a tym samym utrudnić masowy podsłuch komunikacji.

W USA i innych krajach Zachodu kryptografia była traktowana jak technologia strategiczna. Możliwość, że każdy użytkownik komputerów będzie mógł szyfrować w sposób praktycznie niełamliwy dla państwowych służb, budziła sprzeciw. Zaczęto myśleć o regulacjach eksportu kryptografii, kontrolowaniu długości kluczy oraz ograniczaniu publicznego dostępu do „zbyt mocnych” algorytmów.

To napięcie między otwartą nauką a państwową tajemnicą będzie powracać przez całe lata 80. i 90., wybuchając np. w sporze wokół Clipper Chip i regulacji eksportu kryptografii, a później bezpośrednio wpływając na jakość SSL oraz HTTPS.

Równoległe, tajne początki – prace w GCHQ przed Diffie-Hellmanem

James Ellis, Clifford Cocks i Malcolm Williamson – zapomniani pionierzy

Dopiero w latach 90. świat się dowiedział, że koncepcje kryptografii publicznej powstały wcześniej w tajnych ośrodkach. W brytyjskim GCHQ (Government Communications Headquarters) James Ellis już na początku lat 70. rozważał możliwość komunikacji szyfrowanej bez wcześniejszego dzielenia się sekretem. Brakowało mu jednak konkretnego mechanizmu matematycznego.

W 1973 roku do gry wkroczył Clifford Cocks, młody matematyk. Opracował on system kryptograficzny bardzo zbliżony do tego, co kilka lat później zostało opublikowane jako RSA. Dwa lata później Malcolm Williamson stworzył rozwiązanie odpowiadające mechanizmowi wymiany klucza Diffie-Hellmana.

Te trzy nazwiska – Ellis, Cocks, Williamson – przez wiele lat pozostawały niemal nieznane. Cała ich praca była sklasyfikowana jako ściśle tajna, ponieważ dotyczyła technologii mogących mieć wpływ na wywiad i bezpieczeństwo państwa.

Koncepcja klucza publicznego w dokumentach niejawnych

GCHQ miało teoretycznie wszystko, co było potrzebne do zbudowania nowoczesnej kryptografii z kluczem publicznym: model koncepcyjny komunikacji bez wspólnego sekretu (Ellis), praktyczny algorytm szyfrowania podobny do RSA (Cocks) oraz protokół wymiany klucza podobny do Diffie-Hellmana (Williamson). Ta wiedza jednak nie trafiła do świata cywilnego.

Oznaczało to, że gdy Diffie, Hellman, Rivest, Shamir i Adleman niezależnie opracowywali swoje rozwiązania, nie mieli dostępu do wcześniejszych prac GCHQ. Historia potoczyła się tak, jakby te odkrycia w GCHQ nigdy nie miały miejsca – aż do odtajnienia dokumentów po latach.

Dlaczego odkrycia GCHQ nie zmieniły od razu świata

Dla inżyniera działającego w realiach zimnej wojny priorytet był prosty: przewaga wywiadowcza. GCHQ traktowało nowe koncepcje kryptograficzne jako narzędzie operacyjne, a nie technologię do komercjalizacji. Ujawnienie szczegółów algorytmów oznaczałoby, że potencjalni przeciwnicy również zyskają dostęp do mocnych szyfrów, utrudniając działania służb.

Instytucje wywiadowcze funkcjonują w innym modelu niż środowisko akademickie:

• ważniejsza jest tajność wyników niż otwarta wymiana myśli,
• miernikiem sukcesu jest skuteczność operacyjna, a nie liczba cytowań,
• nowa technologia jest zasobem do wykorzystania, a nie standardem do popularyzacji.

W efekcie GCHQ nie miało motywacji, by promować kryptografię publiczną w sektorze cywilnym czy w rodzącym się świecie sieci komputerowych. Odkrycia Ellisa, Cocksa i Williamsona pozostały więc przez dekady zamknięte w sejfach. Technicznie rzecz biorąc, pierwszy praktyczny „RSA” istniał, ale nie mógł trafić do protokołów takich jak SSL – po prostu nikt z projektantów tych rozwiązań o nim nie wiedział.

Odtajnienie i „podwójne odkrycie”

Dopiero w 1997 roku GCHQ oficjalnie ujawniło, że pionierskie prace nad kryptografią z kluczem publicznym prowadziło już na początku lat 70. Dla społeczności kryptograficznej był to klasyczny przykład niezależnego, podwójnego odkrycia. Z perspektywy SSL i HTTPS istotne są dwie konsekwencje:

• standardy internetowe oparte na RSA, Diffie-Hellmanie i podpisach cyfrowych powstały bez ingerencji służb w same algorytmy; to ważne przy zaufaniu do tych prymitywów,
• spór o kontrolę nad szyfrowaniem rozgrywał się już nie na poziomie konstrukcji matematycznych, lecz polityki, regulacji eksportu i długości kluczy.

Historia GCHQ pokazuje, że to nie brak wiedzy, lecz model zarządzania tą wiedzą decydował o tym, kiedy kryptografia asymetryczna trafiła do cywilnego Internetu.

RSA i pierwsze praktyczne algorytmy kryptografii asymetrycznej

Rivest, Shamir, Adleman – matematyka w służbie praktyki

W 1977 roku Ron Rivest, Adi Shamir i Leonard Adleman z MIT szukali algorytmu, który wpasuje się w model Diffiego i Hellmana. Chodziło o konkretny mechanizm, w którym:

• łatwo wykonać operację szyfrowania i podpisywania,
• trudno odwrócić tę operację bez znajomości sekretu,
• obliczenia są wykonalne na ówczesnym sprzęcie komputerowym.

Rozwiązaniem okazał się system oparty na trudności faktoryzacji dużych liczb. Tak narodził się algorytm RSA, nazwany od nazwisk twórców. Z dzisiejszej perspektywy jest to klasyk, ale wtedy był to odważny pomysł: oprzeć bezpieczeństwo systemu na fakcie, że nikt nie potrafi szybko rozkładać bardzo dużych liczb złożonych na czynniki pierwsze.

Jak działa RSA – intuicyjny obraz

W uproszczonej wersji mechanizm RSA można streścić w kilku krokach:

1. Wybiera się dwie duże liczby pierwsze p i q oraz oblicza ich iloczyn n = p · q. Liczba n staje się częścią klucza publicznego.
2. Na podstawie własności p i q wylicza się dwie potęgi: jedną publiczną (e), drugą prywatną (d), powiązane ze sobą przez zależność modularną.
3. Szyfrowanie sprowadza się do podniesienia wiadomości (zamienionej na liczbę) do potęgi e modulo n.
4. Deszyfrowanie to podniesienie wyniku do potęgi d modulo n.

Bez znajomości czynników p i q odtworzenie klucza prywatnego d z publicznego e i n jest w praktyce niewykonalne, o ile liczby są odpowiednio duże. Właśnie ta asymetria – łatwość w jedną stronę, trudność w drugą – jest sercem kryptografii z kluczem publicznym.

Z punktu widzenia HTTPS kluczowe są dwie cechy RSA:

• możliwość szyfrowania krótkich sekretów (np. klucza sesji),
• możliwość tworzenia podpisów cyfrowych, które można weryfikować przy użyciu publicznego certyfikatu serwera.

RSA jako narzędzie do dystrybucji kluczy symetrycznych

RSA nie jest wygodne do szyfrowania dużych strumieni danych – operacje na bardzo dużych liczbach są kosztowne. Świetnie nadaje się natomiast do szyfrowania krótkich wartości, takich jak:

• losowy klucz sesji dla algorytmu symetrycznego (np. AES),
• materiał początkowy do funkcji wyprowadzania kluczy.

Model użycia, który ostatecznie przyjął się w SSL/TLS, wygląda tak: RSA służy jedynie do bezpiecznego przekazania klucza, a cała właściwa komunikacja (HTTP w tunelu TLS) jest szyfrowana szyframi symetrycznymi. To połączenie praktyczności i bezpieczeństwa:

• RSA zapewnia, że tylko właściciel klucza prywatnego serwera pozna tajny klucz sesji,
• szyfr symetryczny zapewnia wydajne szyfrowanie dużych ilości danych w trakcie sesji HTTPS.

Podpisy cyfrowe i autentyczność serwera

Drugą właściwością RSA, kluczową dla HTTPS, jest możliwość generowania podpisów cyfrowych. Mechanizm jest odwrotny do szyfrowania:

1. serwer oblicza skrót (hash) z treści, którą chce podpisać (np. z danych w certyfikacie),
2. podnosi ten skrót do potęgi d (klucz prywatny) modulo n, tworząc podpis,
3. klient weryfikuje podpis, używając klucza publicznego z certyfikatu (potęga e modulo n),
4. jeśli wynik zgadza się z samodzielnie policzonym skrótem, podpis jest poprawny.

Ten sam schemat stosuje się w łańcuchu zaufania certyfikatów: urząd certyfikacji (CA) podpisuje certyfikat serwera swoim kluczem prywatnym, a przeglądarka weryfikuje ten podpis przy użyciu publicznego klucza CA wbudowanego w system.

Patent na RSA i jego wpływ na wczesne wdrożenia

W 1983 roku algorytm RSA został opatentowany w USA (patent US 4,405,829), który wygasł dopiero w 2000 roku. RSA Data Security (później RSA Security) miała ograniczoną kontrolę nad komercyjnym użyciem tej technologii na terenie Stanów Zjednoczonych. To miało bezpośrednie skutki dla projektantów protokołów bezpieczeństwa:

• implementacje komercyjne wymagały licencji,
• twórcy wolnego oprogramowania szukali alternatyw lub implementowali RSA poza jurysdykcją USA,
• powstawały warianty protokołów, które próbowały omijać ograniczenia patentowe (np. preferując Diffie-Hellmana lub inne mechanizmy).

Dopiero wygaśnięcie patentu ułatwiło szeroką adopcję RSA w standardach internetowych bez obaw prawnych, co zbiegło się w czasie z gwałtowną popularyzacją HTTPS na początku XXI wieku.

Wojny kryptologiczne i spór o kontrolę nad szyfrowaniem

Kryptografia jako „amunicja” – regulacje eksportowe

W latach 80. i na początku 90. rządy USA traktowały kryptografię porównywalnie do broni. Silne algorytmy szyfrujące formalnie kwalifikowano jako towary podwójnego zastosowania lub wręcz „amunicję” (munitions). Eksport oprogramowania z mocną kryptografią podlegał ścisłej kontroli.

Praktyczny efekt był taki, że:

• oprogramowanie sprzedawane poza USA musiało stosować osłabione warianty kryptografii (np. 40-bitowe klucze),
• firmy tworzyły osobne „export versions” swoich produktów, co komplikowało rozwój,
• podstawowe biblioteki kryptograficzne (np. wczesne implementacje SSL) zawierały tryby „export-grade”, które po latach stały się źródłem poważnych podatności.

W kontekście HTTPS skutkiem było to, że przez długi czas wiele przeglądarek i serwerów obsługiwało zarówno mocne, jak i słabe zestawy szyfrów (cipher suites). Samo istnienie trybów exportowych doprowadziło po latach do ataków takich jak FREAK czy Logjam, gdzie napastnik wymuszał negocjację zbyt słabego szyfrowania.

PGP, Phil Zimmermann i pierwsza fala konfliktu

Na początku lat 90. Phil Zimmermann stworzył Pretty Good Privacy (PGP), system szyfrowania poczty elektronicznej oparty na kryptografii z kluczem publicznym. Udostępnił go publicznie, bez ograniczeń eksportowych. Władze USA uznały, że doszło do nielegalnego eksportu technologii szyfrującej.

Sprawa PGP miała kilka ważnych konsekwencji:

• pokazała, że silna kryptografia może zostać rozprzestrzeniona globalnie w sposób trudny do kontrolowania (np. poprzez wydruk kodu źródłowego w formie książki, która nie podlegała takim restrykcjom),
• uwypukliła konflikt między prawem do prywatności a chęcią państwa do kontrolowania szyfrowania,
• uświadomiła opinii publicznej, że kryptografia przestała być domeną służb i wojska, a stała się narzędziem zwykłych użytkowników.

To napięcie później przeniosło się na obszar komunikacji WWW – skoro użytkownicy chcą, aby ich poczta była prywatna, to tym bardziej będą oczekiwać prywatności w transakcjach i logowaniu do serwisów internetowych.

Clipper Chip i pomysł „tylnych drzwi”

Rząd USA w latach 90. promował koncepcję tzw. Clipper Chip – specjalnego układu kryptograficznego z wbudowanym mechanizmem key escrow. Idea była prosta: zwykli użytkownicy mogą korzystać z szyfrowania, ale państwo zachowuje możliwość odszyfrowania danych po odpowiedniej procedurze prawnej (dzięki przechowywaniu kopii kluczy w rządowych sejfach).

Środowisko techniczne i organizacje broniące praw obywatelskich krytykowały ten pomysł z kilku powodów:

• technicznie: każda forma key escrow tworzy centralny punkt ataku – jeśli baza kluczy wycieknie, wszystkie systemy oparte na tym mechanizmie stają się niebezpieczne,
• organizacyjnie: trudno zagwarantować, że mechanizm będzie wykorzystywany tylko w ściśle uzasadnionych przypadkach,
• rynkowo: rozwiązanie ograniczone do jednego kraju traci sens w globalnej gospodarce.

Ostatecznie projekt Clipper Chip upadł, ale sam spór miał dalekosiężne skutki. W praktyce przyspieszył rozwój otwartych, bez „tylnych drzwi” standardów kryptograficznych, które później stały się fundamentem SSL/TLS i HTTPS.

Poluzowanie kontroli i „normalizacja” kryptografii

Pod koniec lat 90. rządy stopniowo luzowały restrykcje eksportowe dotyczące kryptografii. Zadziałało kilka czynników:

• Internet stawał się infrastrukturą gospodarczą, a nie tylko naukową czy wojskową,
• firmy finansowe, sklepy internetowe i dostawcy usług domagali się silnego szyfrowania, bo bez niego transakcje online byłyby zbyt ryzykowne,
• technicznie i praktycznie nie dało się już cofnąć globalnego rozpowszechnienia kryptografii (chociażby przez wolne oprogramowanie).

Przestaną wtedy mieć sens słabe, „eksportowe” warianty algorytmów. Od tej chwili kierunek był już jasny: mocna kryptografia trafi do powszechnego użytku, a nie będzie ograniczona do wybranych sektorów. Tworzyło to klimat sprzyjający upowszechnieniu SSL/TLS w przeglądarkach i serwerach WWW.

Początki WWW i pierwsze próby zabezpieczania połączeń

HTTP w wersji „nagiej” – brak poufności i uwierzytelnienia

Protokół HTTP powstał na początku lat 90. jako prosty sposób przesyłania dokumentów hipertekstowych. Zakładano środowisko zaufane – głównie sieci akademickie i badawcze. W podstawowej wersji HTTP:

• treść żądań i odpowiedzi nie jest szyfrowana,
• nagłówki i adresy URL są widoczne wprost dla każdego, kto ma dostęp do ruchu sieciowego,

Pierwsze potrzeby bezpieczeństwa: hasła, koszyki i karty płatnicze

HTTP świetnie nadawał się do publikowania statycznych stron, ale bardzo szybko pojawiły się scenariusze, w których brak szyfrowania stał się poważnym problemem. Najpierw były to proste logowania do paneli administracyjnych czy systemów poczty webowej, później – zakupy online i płatności kartą.

W praktyce wyglądało to tak: użytkownik wpisywał login i hasło w formularzu, przeglądarka wysyłała je w żądaniu POST, a każdy, kto podsłuchiwał ruch (np. w tej samej sieci lokalnej), mógł odczytać dane wprost z pakietów. Przy płatnościach kartą dochodziły numery kart i dane osobowe.

Jeśli administrator miał świadomość ryzyk, próbował stosować półśrodki:

• maskowanie haseł po stronie klienta (np. prostym JavaScriptem, co nie dawało realnego bezpieczeństwa),
• logowanie z zaufanych sieci, np. tylko z intranetu firmy,
• oddzielne systemy do płatności obsługiwane ręcznie, bez pełnej integracji z WWW.

Wraz z rozwojem handlu elektronicznego stało się jasne, że potrzeba standardowego mechanizmu zapewniającego poufność i integralność ruchu HTTP w sieci publicznej. Rozwiązanie musiało być przezroczyste dla aplikacji WWW – tak, aby ten sam kod CGI czy skryptu serwerowego mógł działać zarówno przez „zwykłe” HTTP, jak i przez bezpieczny kanał.

Eksperymenty NCSA i pierwsze „szyfrowane” serwery HTTP

Jednym z pierwszych popularnych serwerów WWW był NCSA HTTPd, rozwijany na Uniwersytecie Illinois. Wokół niego pojawiały się eksperymentalne łatki dodające proste formy szyfrowania transportu, często oparte na niestandaryzowanych implementacjach algorytmów symetrycznych.

Te prototypowe rozwiązania miały kilka cech wspólnych:

• brak ustandaryzowanego mechanizmu negocjowania algorytmów i parametrów (wersja, szyfr, długości kluczy),
• brak spójnego modelu zaufania i certyfikatów – klucze publiczne serwerów często były wbudowane „na sztywno” lub wymieniane ręcznie,
• silne powiązanie konkretnej implementacji szyfrowania z konkretną wersją serwera i przeglądarki.

Takie podejście mogło działać w kontrolowanym środowisku (np. w sieci korporacyjnej), ale nie nadawało się do globalnego Internetu. Potrzebny był powszechnie uznany protokół, z jasno zdefiniowanym handshake’iem, zestawem szyfrów i infrastrukturą kluczy publicznych.

Projekt Netscape: od S-HTTP do SSL

Na początku lat 90. Netscape Communications stał się jednym z głównych graczy w obszarze przeglądarek i serwerów WWW. Wraz ze wzrostem popularności komercyjnego Internetu Netscape bardzo szybko zderzył się z problemem bezpiecznych transakcji. To tam narodził się Secure Sockets Layer (SSL).

W tym samym czasie inne podmioty rozwijały alternatywne podejścia, np. S-HTTP (Secure HTTP) autorstwa EIT (Enterprise Integration Technologies). Różnica koncepcyjna była istotna:

• S-HTTP próbował zabezpieczać same komunikaty HTTP – każdy dokument lub żądanie mogło być osobno zaszyfrowane/podpisane,
• SSL zostało zaprojektowane jako warstwa poniżej HTTP, działająca między TCP a aplikacją – dzięki temu mogło zabezpieczać dowolny protokół, nie tylko HTTP.

S-HTTP dawał bardzo elastyczny model bezpieczeństwa (np. różne polityki dla różnych zasobów), ale był skomplikowany w implementacji i wymagał głębokich zmian po stronie aplikacji WWW. SSL, jako warstwa transportowa, miało prostszą integrację: aplikacja dalej „widziała” zwykłe połączenie strumieniowe, tyle że chronione.

Rynek szybko zweryfikował te podejścia. Ostatecznie to SSL (a później TLS) stał się fundamentem HTTPS, a S-HTTP pozostał ciekawostką historyczną.

SSL 1.0 i 2.0 – pierwsze kroki i pierwsze błędy

Pierwsze wewnętrzne wersje SSL w Netscape (oznaczane jako 1.0) nigdy nie trafiły oficjalnie do szerokiego użytku – szybko wykryto istotne błędy bezpieczeństwa. Publicznie zadebiutował SSL 2.0 na początku lat 90. i był wykorzystywany w przeglądarce Netscape Navigator.

SSL 2.0 wprowadzał już podstawowe elementy znane z późniejszych wersji:

• handshake negocjujący zestaw szyfrów (cipher suite),
• wykorzystanie RSA do przekazania losowego sekretu, z którego wyprowadzano klucze sesyjne,
• oddzielne klucze dla kierunku klient→serwer i serwer→klient,
• możliwość stosowania podpisanych certyfikatów X.509 do uwierzytelnienia serwera.

Jednocześnie implementacja SSL 2.0 zawierała poważne braki konstrukcyjne:

• brak ochrony integralności części handshake’u, co umożliwiało pewne formy ataków typu downgrading,
• słabe połączenie pomiędzy danymi handshake’u a kluczami sesyjnymi (łatwiej było manipulować parametrami),
• brak jasnego rozdziału pomiędzy komunikatami błędów a zwykłym ruchem, co sprzyjało przeciekom informacji.

Po kilku latach obecności w sieci SSL 2.0 stał się źródłem znanych podatności. Z perspektywy czasu jego największą zaletą było jednak coś innego: udowodnił w praktyce, że masowy, szyfrowany handel online jest możliwy. To wystarczyło, by zainwestować w poprawioną wersję.

SSL 3.0 – spotkanie kryptografii akademickiej z praktyką WWW

Przełomem stał się SSL 3.0, rozwijany m.in. przy współudziale Paula Kocher’a. W tej wersji widać już wyraźne odzwierciedlenie dorobku kryptografii akademickiej w konstrukcji protokołu.

SSL 3.0 wprowadził szereg usprawnień, które przetrwały do TLS 1.0 i później:

• kompletne uwierzytelnienie handshake’u – końcowy komunikat Finished jest MAC-owany z użyciem materiału kluczowego zależnego od wszystkich poprzednich wiadomości,
• elastyczniejszy mechanizm wymiany kluczy, obejmujący nie tylko RSA, ale także Diffie-Hellmana,
• możliwość późniejszego dodawania nowych szyfrów i algorytmów skrótu bez zmiany całego protokołu,
• zdecydowanie lepszy model obsługi błędów i zamykania połączeń.

Istotny był także sposób projektowania: protokół analizowano już nie tylko pod kątem „czy działa”, ale czy odporność na znane klasy ataków (powtórzeniowe, downgrading, modyfikacja ruchu) jest możliwa do formalnego uzasadnienia. W tym sensie SSL 3.0 był mostem między teorią kryptografii publicznej a wymaganiami rosnącego WWW.

HTTPS – prosty pomysł na połączenie HTTP i SSL

Sama kryptografia transportowa nie wystarczy – aplikacje muszą mieć sposób, by z niej korzystać. W przypadku WWW zdecydowano się na bardzo prostą konwencję: HTTPS to po prostu HTTP przesyłany przez kanał SSL/TLS, zwykle na porcie 443.

Mechanizm wygląda z grubsza tak:

1. przeglądarka nawiązuje połączenie TCP z serwerem na porcie 443,
2. inicjuje handshake SSL/TLS, negocjując wersję protokołu i zestaw szyfrów,
3. w trakcie handshake’u serwer prezentuje swój certyfikat z kluczem publicznym,
4. po wyprowadzeniu wspólnego klucza sesji cała dalsza komunikacja HTTP jest szyfrowana i uwierzytelniana.

Od strony programisty aplikacji różnica sprowadzała się często do konfiguracji serwera (np. https:// zamiast http:// i odpowiednie certyfikaty). Skrypty CGI, moduły PHP czy Java Servlets mogły działać bez zmian logicznych – informacje o tym, czy połączenie jest „bezpieczne”, były dostępne przez zmienne środowiskowe lub API serwera.

Takie „opakowanie” HTTP miało kilka kluczowych konsekwencji:

• dawało natychmiastową kompatybilność z istniejącą infrastrukturą WWW,
• ułatwiało wdrożenia – administratorzy mogli stopniowo dodawać HTTPS do wybranych ścieżek (np. tylko logowanie i płatności),
• otwierało drogę do późniejszego wymuszania „pełnego HTTPS” w serwisach, gdy świadomość bezpieczeństwa rosła.

Certyfikaty X.509 i narodziny komercyjnych urzędów certyfikacji

Klucz publiczny serwera musi być powiązany z jego tożsamością w sposób, który klient może zweryfikować. W HTTPS tę rolę pełnią certyfikaty X.509, podpisywane przez urzędy certyfikacji (CA).

Model zaufania wygląda w uproszczeniu następująco:

• przeglądarka lub system operacyjny posiada zestaw zaufanych kluczy publicznych CA (tzw. root CA),
• serwer przedstawia swój certyfikat zawierający nazwę domeny i klucz publiczny, podpisany przez CA,
• klient weryfikuje podpis na certyfikacie serwera, używając klucza CA, który już zna,
• jeśli podpis jest poprawny, a nazwa domeny zgadza się z adresem w pasku URL, przeglądarka uznaje połączenie za uwierzytelnione.

Ten model był bezpośrednim zastosowaniem koncepcji kryptografii publicznej w skali globalnej. Zaufanie do niewielkiej liczby urzędów certyfikacji umożliwiało transmisję bezpiecznych kluczy dla milionów serwerów WWW. Jednocześnie tworzył się nowy rynek: komercyjne CA sprzedawały certyfikaty, a przeglądarki decydowały, które z nich trafią do listy zaufanych.

Od strony technicznej zastosowano dwa kluczowe mechanizmy oparte na RSA (później także na innych algorytmach asymetrycznych):

• podpis cyfrowy certyfikatu – CA podpisuje strukturę zawierającą klucz publiczny, nazwę domeny, okres ważności i parametry użycia,
• uwierzytelnienie serwera w handshake’u TLS – serwer wykazuje, że posiada klucz prywatny odpowiadający kluczowi publicznemu z certyfikatu, podpisując dane z handshake’u.

Bez tych mechanizmów HTTPS dawałby co najwyżej szyfrowanie „do kogokolwiek” – ruch byłby trudniejszy do podsłuchania, ale użytkownik nie miałby gwarancji, że rozmawia z właściwym serwerem, a nie z napastnikiem w ataku typu man-in-the-middle.

HTTPS a ograniczenia patentowe i tryby „export-grade” w praktyce

Wczesne wdrożenia HTTPS funkcjonowały pod presją dwóch rodzajów ograniczeń: patentów na RSA i regulacji eksportowych. To bezpośrednio wpłynęło na parametry kryptograficzne, które spotykało się w praktyce.

Serwery i przeglądarki musiały obsługiwać zarówno mocne, jak i słabe zestawy szyfrów, w tym:

• RSA z krótkimi kluczami (np. 512-bitowymi) w wariantach eksportowych,
• słabe szyfry symetryczne (40 lub 56 bitów),
• alternatywne mechanizmy wymiany kluczy oparte na Diffie-Hellmanie z ograniczonymi parametrami.

Na poziomie protokołu TLS/SSL zdefiniowano wiele cipher suites, z których część była oznaczona jako „EXPORT”. Przeglądarki często priorytetowo wybierały najsilniejszy wspólny zestaw, ale w niektórych konfiguracjach serwery preferowały zgodność z przepisami eksportowymi nad bezpieczeństwem.

Decyzje administracyjne prowadziły czasem do absurdów. Przykładowo:

• serwis dostępny globalnie mógł oferować silne szyfrowanie tylko użytkownikom z określonych krajów, a pozostałym – osłabioną wersję,
• uczelniane serwery w Europie lub Azji instalowały biblioteki kryptograficzne skompilowane poza USA, by ominąć patenty, jednocześnie współpracując z przeglądarkami opartymi na amerykańskim kodzie.

Dopiero wygasanie patentów i liberalizacja przepisów pozwoliły w końcu usunąć z głównych implementacji wsparcie dla „export-grade” i przejść na jednolicie silną kryptografię, co znacząco poprawiło realne bezpieczeństwo HTTPS.

Od RSA-only do miksu RSA, Diffie-Hellmana i krzywych eliptycznych

W pierwszych latach dominował model, w którym RSA obsługiwało zarówno uwierzytelnienie, jak i wymianę sekretu. Z czasem zaczęto odchodzić od tej koncentracji na jednym algorytmie.

Powody były zarówno praktyczne, jak i teoretyczne:

• obawy przed pojedynczym punktem załamania – jeśli factoring dużych liczb stałby się szybszy (np. przez nowe algorytmy lub komputery kwantowe), cała infrastruktura oparta na RSA byłaby zagrożona,

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica między kryptografią symetryczną a asymetryczną?

Kryptografia symetryczna używa jednego, wspólnego klucza do szyfrowania i deszyfrowania. Ten sam sekret muszą znać zarówno nadawca, jak i odbiorca, a całe bezpieczeństwo zależy od utrzymania go w tajemnicy. Przykładami są klasyczne szyfry (Cezara, Vigenère’a) oraz współczesne DES czy AES.

Kryptografia asymetryczna (z kluczem publicznym) wykorzystuje parę kluczy: publiczny i prywatny. Klucz publiczny można udostępniać wszystkim, natomiast prywatny zna tylko właściciel. Szyfrowanie odbywa się kluczem publicznym, a odszyfrowanie – odpowiadającym mu kluczem prywatnym. Dzięki temu dwie strony mogą bezpiecznie zacząć rozmowę, mimo że nigdy wcześniej nie wymieniły sekretu.

Dlaczego klasyczna kryptografia symetryczna przestała wystarczać w sieci Internet?

Model symetryczny załamuje się przy dużej skali. Jeśli każda para uczestników sieci ma mieć swój unikalny klucz, liczba kluczy rośnie mniej więcej jak N(N−1)/2. Przy kilku osobach to jeszcze działa, ale dla banków, sklepów internetowych i milionów użytkowników jest to niewykonalne organizacyjnie.

Drugi problem to bezpieczna wymiana kluczy. Skoro kanał jest na początku niezaszyfrowany, każdy podsłuchujący może przechwycić przekazywany klucz. W świecie papierowych depesz można było wysłać kuriera dyplomatycznego, w globalnej sieci komputerowej taki model już się nie broni. Kryptografia z kluczem publicznym rozwiązuje oba te problemy.

Kim byli Diffie i Hellman i na czym polegał ich przełom?

Whitfield Diffie i Martin Hellman to badacze, którzy w 1976 roku opublikowali pracę „New Directions in Cryptography”. Sformalizowali w niej koncepcję kryptografii z kluczem publicznym i prywatnym oraz zarysowali ideę podpisu cyfrowego. Nie przedstawili jeszcze gotowego, praktycznego algorytmu szyfrującego, ale zaproponowali spójny model matematyczny.

Ich przełom polegał na rozdzieleniu funkcji szyfrowania i deszyfrowania. Zaproponowali, by jedna część informacji (klucz publiczny) była jawna, a druga (klucz prywatny) pozostała tajna, przy czym z publicznej nie da się w praktyce uzyskać prywatnej. To otworzyło drogę do bezpiecznej komunikacji bez wcześniejszej wymiany sekretu, co było kluczowe dla rozwoju późniejszego SSL/TLS.

Dlaczego rozwój sieci komputerowych wymusił powstanie kryptografii publicznej?

W sieciach takich jak ARPANET pojawiły się nowe potrzeby: zdalne logowanie, przesyłanie plików, poczta elektroniczna między ośrodkami, które nigdy się nie spotkały. Gdy do tego doszły wizje bankowości internetowej i handlu elektronicznego, okazało się, że klasyczny model „najpierw bezpiecznie wymieńmy klucz, potem szyfrujmy” przestaje działać.

Komputer w jednym mieście musi móc bezpiecznie porozmawiać z serwerem na innym kontynencie bez kurierów i przygotowań. Kryptografia publiczna pozwala opublikować klucz publiczny (np. w certyfikacie serwera), tak aby każdy mógł od razu zacząć szyfrować do danego odbiorcy, nie znając wcześniej żadnego wspólnego sekretu.

Jak kryptografia z kluczem publicznym trafiła do SSL/TLS i HTTPS?

W protokołach SSL/TLS (a więc także w HTTPS) kryptografia asymetryczna jest używana głównie na początku połączenia. Przeglądarka pobiera certyfikat serwera zawierający jego klucz publiczny, sprawdza, czy został on wystawiony przez zaufane centrum certyfikacji, a następnie wykorzystuje go do bezpiecznego uzgodnienia klucza sesyjnego.

Dalsza komunikacja odbywa się zwykle przy użyciu szyfrów symetrycznych (np. AES), ponieważ są znacznie szybsze i lepiej nadają się do przesyłania dużych ilości danych. Kryptografia publiczna rozwiązuje więc problem startu: bezpiecznego uzgodnienia wspólnego klucza i uwierzytelnienia serwera, a symetryczna przejmuje „codzienną” pracę szyfrowania ruchu.

Dlaczego w HTTPS potrzebne są zarówno szyfry symetryczne, jak i asymetryczne?

Szyfry asymetryczne są elastyczne organizacyjnie (klucz publiczny można rozpowszechnić każdemu), ale są wolne i obciążają procesor. Szyfry symetryczne są bardzo szybkie i idealnie nadają się do ochrony dużych strumieni danych, ale wymagają wcześniejszej wymiany wspólnego klucza.

HTTPS łączy oba światy:

• kryptografia asymetryczna – do uzgadniania kluczy i uwierzytelniania (certyfikaty, klucze publiczne serwerów),
• kryptografia symetryczna – do szyfrowania właściwej treści strony, danych logowania, informacji o płatnościach.

Dzięki temu da się jednocześnie zachować wysokie bezpieczeństwo i rozsądne wymagania sprzętowe, nawet przy milionach połączeń dziennie.

Jakie problemy organizacyjne rozwiązuje kryptografia publiczna w porównaniu z symetryczną?

Kryptografia publiczna eliminuje konieczność utrzymywania ogromnej liczby tajnych kluczy między parami uczestników oraz potrzebę ich fizycznej dystrybucji. Wystarczy, że każda strona ma własną parę kluczy i udostępnia swój klucz publiczny. Liczba kluczy rośnie liniowo z liczbą podmiotów, a nie kwadratowo z liczbą połączeń.

Dodatkowo umożliwia skalowalne uwierzytelnianie. Bank, sklep czy urząd mogą potwierdzić swoją tożsamość za pomocą certyfikatu i podpisu cyfrowego, a klient nie musi wcześniej znać żadnego wspólnego sekretu. To właśnie ten mechanizm sprawia, że codziennie można bezpiecznie logować się do nieznanych wcześniej serwisów WWW, sprawdzając jedynie, czy przeglądarka ufa ich certyfikatom.

Kluczowe Wnioski

• Kryptografia klasyczna i wojskowa aż do drugiej połowy XX wieku opierała się niemal wyłącznie na modelu symetrycznym – jeden wspólny tajny klucz musiał być wcześniej bezpiecznie uzgodniony przez nadawcę i odbiorcę.
• Największym praktycznym problemem kryptografii symetrycznej okazała się dystrybucja kluczy: bezpieczne przekazanie sekretu wymaga już istnienia innego bezpiecznego kanału, co w dużych, rozproszonych systemach prowadzi do błędnego koła.
• Wraz ze wzrostem liczby uczestników sieci liczba wymaganych kluczy symetrycznych rośnie w przybliżeniu jak N(N−1)/2, co przy tysiącach czy milionach potencjalnych par komunikujących się stron staje się organizacyjnie nie do opanowania.
• Rozwój sieci komputerowych (ARPANET, pierwsze protokoły jak telnet czy FTP) ujawnił, że modele z czasów „kurierów i sejfów” nie skalują się do dynamicznej, globalnej infrastruktury, w której komputery komunikują się z nieznanymi wcześniej partnerami.
• Cyfrowy handel i masowe usługi sieciowe wymagają nie tylko poufności, lecz także silnego uwierzytelnienia drugiej strony (np. czy to naprawdę bank), czego nie da się efektywnie zapewnić wyłącznie przez wcześniej uzgadniane sekrety symetryczne.
• Potrzeba bezpiecznej komunikacji bez uprzedniej wymiany tajnego klucza stała się impulsem do poszukiwań nowych modeli matematycznych – idei rozdzielenia funkcji szyfrowania i deszyfrowania, które każdy mógłby częściowo znać bez utraty bezpieczeństwa.