szyfrowanie end-to-end (E2EE)

Szyfrowanie end-to-end (end-to-end encryption, E2EE) to szyfrowanie, w którym klucze do odczytu treści mają wyłącznie urządzenia nadawcy i odbiorcy. Serwer usługi przenosi wiadomość, ale nie potrafi jej odczytać. NIST opisuje je jako szyfrowanie komunikacji, w którym dane są zaszyfrowane podczas przejścia przez sieć, a informacje o trasowaniu pozostają widoczne ^[1]. Ta druga część definicji jest ważna: szyfrowanie end-to-end chroni treść, lecz nie ukrywa, kto, kiedy i z kim się komunikuje.

Jak działa

Nadawca szyfruje wiadomość na swoim urządzeniu kluczem, którego nie zna nikt poza stronami rozmowy. Serwer dostaje szyfrogram, przechowuje go i przekazuje dalej. Odbiorca odszyfrowuje treść dopiero u siebie. Podstawą jest zwykle kryptografia asymetryczna: każde urządzenie ma parę kluczy, a klucz publiczny służy do uzgodnienia wspólnego sekretu z rozmówcą.

Nowoczesne protokoły idą dalej i zmieniają klucze w trakcie rozmowy. Algorytm Double Ratchet, używany w protokole Signal, wyprowadza nowy klucz dla każdej wiadomości, tak aby wcześniejszych kluczy nie dało się obliczyć z późniejszych ^[3]. Daje to forward secrecy, czyli ochronę starych wiadomości po przejęciu bieżącego klucza, oraz tak zwane odzyskanie po włamaniu: przyszłe klucze znów stają się nieprzewidywalne dla napastnika, gdy do obliczeń trafi nowa entropia ^[3].

RYS. 1Wiadomość szyfrowana end-to-end

Nadawca szyfruje treść przed wysłaniem, a odbiorca odszyfrowuje ją dopiero u siebie. Schemat powyżej pokazuje, że serwer widzi tylko szyfrogram i metadane. Tego, co jest w środku, nie odczyta nawet jego operator.

Odmiany

Najważniejsze rozróżnienie dotyczy tego, kto ma klucze. W szyfrowaniu transportowym, takim jak TLS, połączenie jest chronione między klientem a serwerem. RFC 8446 opisuje TLS jako protokół pozwalający aplikacjom klient–serwer komunikować się w sposób zaprojektowany przeciw podsłuchowi, manipulacji i fałszowaniu wiadomości ^[2]. Serwer jest jednak końcem tego tunelu, więc widzi treść w postaci jawnej.

Rozmowy grupowe są trudniejsze, bo klucz trzeba uzgodnić między wieloma urządzeniami, które nie zawsze są jednocześnie online. Protokół Messaging Layer Security, opublikowany przez IETF w lipcu 2023 roku jako RFC 9420, zapewnia asynchroniczne ustalanie klucza grupowego z forward secrecy i bezpieczeństwem po przejęciu, dla grup od dwóch do tysięcy uczestników ^[4]. Serwer dostarczający wiadomości jest w nim traktowany jako w dużej mierze niezaufany ^[4].

W WordPressie

Typowa strona WordPress nie stosuje szyfrowania end-to-end. Formularz kontaktowy, logowanie czy zamówienie w sklepie są chronione przez TLS, czyli certyfikat SSL/TLS i połączenie HTTPS ^[2]. Dane przestają być zaszyfrowane po dotarciu do serwera: widzi je PHP, zapisuje baza danych, a często także wtyczka wysyłająca powiadomienie e-mailem. Dostęp do tych danych ma więc każdy, kto ma dostęp do serwera, panelu hostingu albo kopii bazy.

Z tego wynikają praktyczne wnioski dla właściciela strony:

• Ochrona treści zgłoszeń zależy od bezpieczeństwa serwera, a nie tylko od kłódki w przeglądarce. Luka we wtyczce, na przykład podatność we wtyczce prowadząca do odczytu bazy, ujawnia dane mimo HTTPS.
• Treść formularza przesyłana dalej e-mailem opuszcza stronę i trafia do skrzynek, które są poza kontrolą witryny.
• Kopia zapasowa (backup) bazy zawiera te same dane w postaci jawnej, jeśli nie zaszyfrowano jej osobno.

Szyfrowanie end-to-end na stronie wymagałoby, aby klucze istniały tylko w przeglądarkach stron rozmowy, a serwer nigdy ich nie dostawał. Jest to model komunikatorów, nie typowego CMS-a.

Zagrożenia i skutki

Szyfrowanie end-to-end chroni treść przed operatorem usługi i przed kimś, kto przejmie serwer. Nie chroni przed wszystkim.

• Metadane. Informacje o trasowaniu pozostają widoczne ^[1], a w MLS serwer dostarczający może obserwować częstotliwość wiadomości i zmiany składu grupy ^[4].
• Końce rozmowy. Treść jest jawna na urządzeniach. Oprogramowanie szpiegowskie (spyware) albo infostealer na telefonie odbiorcy czyta wiadomości po odszyfrowaniu.
• Podmiana klucza. Jeśli serwer podsunie fałszywy klucz publiczny, możliwy jest atak man-in-the-middle (MITM). Dlatego komunikatory pozwalają porównać klucze. WhatsApp umożliwia to kodem QR albo porównaniem 60-cyfrowego numeru ^[5].
• Utrata kluczy. Dostawca nie odzyska danych za użytkownika. Apple zaznacza, że przy włączonej zaawansowanej ochronie danych nie ma kluczy, by pomóc w odzyskaniu dostępu, więc użytkownik musi sam zadbać o metody odzyskiwania ^[6].

Dobre praktyki

• Weryfikować klucze rozmówców przy ważnych rozmowach, zwłaszcza po zmianie telefonu.
• Chronić same urządzenia: blokada ekranu, szyfrowanie urządzenia i aktualizacje.
• Ustawić metody odzyskiwania przed włączeniem szyfrowania end-to-end kopii w chmurze. Apple wymaga ich skonfigurowania przed aktywacją zaawansowanej ochrony danych ^[6].
• Nie zakładać, że HTTPS na stronie to szyfrowanie end-to-end. Wrażliwe dane zebrane przez stronę trzeba chronić na serwerze: dostępami, kopiami i minimalizacją tego, co się przechowuje.

Historia i przykłady

5 kwietnia 2016 roku WhatsApp włączył domyślne szyfrowanie end-to-end wszystkich wiadomości, oparte na otwartym protokole Signal firmy Open Whisper Systems ^[5]. Szyfrowanie działało automatycznie, bez specjalnych ustawień, a każda wiadomość dostawała własny klucz ^[5].

W lipcu 2023 roku IETF opublikował RFC 9420 z protokołem MLS do grupowego szyfrowania end-to-end w komunikatorach ^[4]. Specyfikacja Double Ratchet doczekała się czwartej rewizji z 4 listopada 2025 roku ^[3].

Szyfrowanie end-to-end objęło też kopie danych w chmurze. W usłudze iCloud z zaawansowaną ochroną danych szyfrowaniem end-to-end objętych jest 25 kategorii danych, wobec 15 przy ochronie standardowej ^[6].