Szyfrowanie end‑to‑end w 5G: co faktycznie jest chronione, a co pozostaje widoczne

Po co w ogóle szyfrować end‑to‑end w erze 5G?

Różnica między szyfrowaniem E2E a „zwykłym” szyfrowaniem transmisji

Szyfrowanie end‑to‑end (E2E) to sytuacja, w której treść danych jest zaszyfrowana od punktu A do punktu B, a klucze deszyfrujące znajdują się tylko u tych dwóch końców. Nikt po drodze – ani operator 5G, ani dostawca chmury pośredniczącej, ani właściciel routera – nie może realistycznie zajrzeć do środka.

„Zwykłe” szyfrowanie transmisji, np. takie które zapewnia sieć 5G, chroni dane po drodze, ale nie przed tym podmiotem, który je szyfruje. Jeżeli to operator włącza szyfrowanie między telefonem a siecią, to on sam widzi dane w formie jawnej w swoim rdzeniu sieci. Analogicznie – jeśli strona WWW szyfruje ruch HTTPS, to dostawca tej strony ma dostęp do treści, choć operator 5G już nie.

Można to porównać do listu. Szyfrowanie transmisji to list w kopercie przewożony zamkniętą furgonetką – złodziej po drodze ma problem, ale kierowca furgonetki może kopertę otworzyć. Szyfrowanie end‑to‑end to list napisany w prywatnym szyfrze – nawet jeśli ktoś otworzy kopertę, zobaczy jedynie niezrozumiały ciąg znaków.

Dlaczego 5G zwiększa powierzchnię ataku

5G wprowadza ogromną gęstość sieci (więcej stacji bazowych, małe komórki), edge computing, masowe urządzenia IoT oraz zastosowania krytyczne: zdalne roboty w fabrykach, systemy sterowania ruchem, automatyka energetyczna, telemedycyna. To wszystko oznacza więcej punktów, w których dane mogą wyciekać lub być atakowane.

Pojawiają się nowe elementy infrastruktury:

• serwery brzegowe (MEC) z aplikacjami blisko użytkownika,
• wirtualizowane funkcje sieciowe (NFV),
• slice’y sieciowe dedykowane konkretnym usługom,
• masowa komunikacja M2M i IoT.

Każdy z tych elementów może stać się celem ataku, błędu konfiguracji lub błędnie zaufanym podmiotem. Im więcej „kawałków” infrastruktury, tym bardziej rośnie sens, aby część danych była zaszyfrowana od końca do końca, niezależnie od tego, przez ilu pośredników przechodzi.

Co 5G realnie obiecuje w kwestii bezpieczeństwa, a co jest marketingiem

Standardy 5G wprowadzają kilka realnych usprawnień bezpieczeństwa w porównaniu do 4G, m.in. lepszą ochronę identyfikatora abonenta (SUPI/SUCI), bardziej elastyczne mechanizmy uwierzytelniania oraz lepszą ochronę sygnalizacji. To są konkretne kroki, które utrudniają podszywanie się pod sieć czy pasywne podsłuchiwanie identyfikatorów.

Równocześnie część haseł marketingowych sugeruje, że „5G jest z natury bezpieczne”. Tymczasem nawet najlepiej zabezpieczona sieć operatora nie rozwiązuje problemów na poziomie aplikacji: błędnych konfiguracji serwerów, słabych mechanizmów logowania, czy przechowywania danych w chmurze bez szyfrowania. 5G nie sprawi magicznie, że komunikator bez E2E stanie się prywatny, ani że źle zaprojektowane API przestanie wyciekać dane.

Użytkownik smartfona vs firma – dwie zupełnie różne perspektywy

Dla przeciętnego użytkownika smartfona szyfrowanie end‑to‑end w 5G najczęściej oznacza bezpieczny komunikator, przeglądanie stron HTTPS i czasem VPN. Interesuje go głównie to, czy operator i osoby trzecie nie podejrzają treści rozmów, zdjęć i haseł. Jego główne ryzyka to phishing, przejęcie kont, nadmierne profilowanie reklamowe, wycieki danych z aplikacji.

Dla firmy budującej system produkcyjny, flotę robotów, inteligentne miasto czy infrastrukturę energetyczną sprawa wygląda radykalnie inaczej. Tam w grę wchodzą:

• odpowiedzialność prawna za dane,
• potencjalne szkody fizyczne (awarie maszyn, blackouty),
• szpiegostwo przemysłowe i sabotaż,
• integracja wielu sieci: prywatne 5G, chmury, systemy OT/SCADA.

Organizacja nie może opierać się wyłącznie na tym, że „operator coś szyfruje”. Potrzebne jest własne szyfrowanie E2E dla krytycznych danych, kontrola kluczy, segmentacja sieci, osobne strefy bezpieczeństwa i precyzyjna polityka tego, kto i kiedy może odczytać konkretne informacje.

Jak wygląda „stos” bezpieczeństwa w 5G – od radia po aplikację

Warstwa radiowa, sieć operatorska i aplikacja – trzy poziomy ochrony

Bezpieczeństwo w 5G układa się w kilka poziomów. Dla zrozumienia szyfrowania end‑to‑end w 5G kluczowe są trzy z nich:

• warstwa radiowa – połączenie między urządzeniem (UE) a stacją bazową (gNB),
• sieć operatorska 5G – rdzeń sieci (5GC), transport między elementami, sieć międzyoperatorska,
• warstwa aplikacji – protokoły używane przez aplikacje, takie jak TLS, DTLS, protokoły komunikatorów, szyfrowanie danych w aplikacjach.

Na warstwie radiowej 5G stosuje szyfrowanie i integralność sygnalizacji oraz danych użytkownika, aby nikt stojący z anteną obok stacji bazowej nie mógł łatwo podsłuchać czy zmodyfikować transmisji. Pomiędzy elementami sieci rdzeniowej operator zwykle włącza tunelowanie IPsec lub inne mechanizmy, chroniąc dane podczas przechodzenia przez własny transport.

Warstwa aplikacji to inna bajka: to tam żyje szyfrowanie end‑to‑end. Aplikacja może używać TLS, własnego protokołu z E2E, VPN, szyfrowania plików. Szyfrowanie na tym poziomie nie zależy od operatora, tylko od twórcy aplikacji i użytkownika.

Mechanizmy bezpieczeństwa 3GPP w 5G

Standardy 3GPP definiują szereg funkcji bezpieczeństwa, m.in.:

• uwierzytelnianie abonenta (5G AKA) – oparte na sekretnym kluczu K zapisanym na USIM i w bazie operatora,
• szyfrowanie i integralność sygnalizacji NAS i RRC,
• ochrona identyfikatora abonenta poprzez SUCI (zaszyfrowany SUPI),
• mechanizmy ochrony między sieciami (N32, SEPP) dla roamingu.

Te mechanizmy zapewniają, że telefon nie łączy się z przypadkową, nieautoryzowaną siecią, że dane na interfejsie radiowym są zaszyfrowane, a sygnalizacja nie jest łatwo modyfikowana przez atakującego z anteną. To ogromny krok w kierunku bezpieczeństwa infrastruktury.

Jednak wszystkie te warstwy działają pod kontrolą operatora. Oznacza to, że operator jest w stanie odczytać treści pakietów IP przechodzących przez jego sieć (o ile nie są dodatkowo szyfrowane na poziomie aplikacji). Z perspektywy prywatności i szyfrowania end‑to‑end to ważna granica: tam, gdzie kończy się kontrola użytkownika nad kluczami, kończy się prawdziwe E2E.

Paczka w sejfie, furgonetka i autostrada – prosta analogia

Przyda się konkretna analogia, która dobrze oddaje warstwowy charakter bezpieczeństwa w 5G:

• paczka w sejfie – to dane zaszyfrowane E2E w aplikacji (np. komunikator E2E), klucz do sejfu ma tylko nadawca i odbiorca,
• zamknięta furgonetka – to szyfrowanie na poziomie operatora (warstwa radiowa, IPsec między elementami sieci), kierowca furgonetki może otworzyć sejf tylko jeśli dostał do niego klucz, co w przypadku poprawnie zrobionego E2E nigdy nie następuje,
• monitorowana autostrada – to sieć operatora, gdzie logowane są informacje o przejazdach: skąd, dokąd, jak często, o której godzinie.

Szyfrowanie E2E to sejf wewnątrz furgonetki. Szyfrowanie 5G zapewnia furgonetkę, która trudniej jest obrabować po drodze. Monitorowanie autostrady to metadane: czas trasy, kierunek, waga paczki. Operator nie musi znać zawartości sejfu, aby wiedzieć, że ktoś regularnie wysyła ciężkie paczki o określonych porach.

Co dokładnie szyfruje 5G „z pudełka”, zanim pojawi się E2E

Bezpieczeństwo połączenia między urządzeniem a stacją bazową

Pierwszy etap to zestawienie bezpiecznego połączenia między urządzeniem (UE) a stacją bazową (gNB). W 5G odbywa się to poprzez proces uwierzytelniania i ustanowienie kluczy, po którym:

• dane użytkownika na interfejsie radiowym są szyfrowane,
• sygnalizacja RRC (sterowanie połączeniem) jest chroniona szyfrowaniem i integralnością,
• podsłuchiwacz z zewnątrz nie odczyta treści, nawet mając specjalistyczny sprzęt RF.

Ten poziom ochrony działa nawet wtedy, gdy aplikacja nie stosuje żadnego dodatkowego szyfrowania. Jeśli użytkownik łączy się ze stroną HTTP (bez HTTPS), to podsłuch na radiu jest bardzo utrudniony – ale operator, gdy pakiety dotrą do rdzenia sieci, widzi je w formie jawnej. Właśnie dlatego różnica między ochroną na poziomie łącza a szyfrowaniem end‑to‑end jest tak istotna.

Karta SIM/USIM i klucze abonenta w 5G

Każdy abonent 5G ma przypisany tajny klucz K, zapisany na karcie USIM oraz w bazie danych operatora (UDM). Z tego klucza wyprowadzane są dalsze klucze, np. KAMF, które służą do zabezpieczania sygnalizacji i transmisji. Proces 5G AKA sprawia, że:

• sieć ma pewność, że rozmawia z prawdziwym abonentem,
• telefon ma pewność, że łączy się z autoryzowaną siecią (zmniejszona podatność na fałszywe stacje bazowe),
• klucze do szyfrowania transmisji radiowej są unikatowe dla danej sesji.

To solidny fundament bezpieczeństwa na poziomie sieci komórkowej. Jednak ten sam fundament sprawia, że operator ma pełną kontrolę nad tym, co widzi w swojej sieci. Klucze do szyfrowania radiowego są wytwarzane wspólnie przez kartę i sieć, więc po deszyfracji na stacji bazowej dane dalej podróżują w sieci operatora jako „zwykły” ruch IP (dalej chroniony, ale w inny sposób).

Ochrona sygnalizacji i segmentacja wewnątrz sieci operatora

Wewnątrz własnej sieci operator 5G korzysta z różnych form ochrony:

• IPsec lub inne protokoły szyfrowania między elementami sieci (gNB – 5GC, funkcje sieciowe, węzły brzegowe),
• segmentacja i sieci wirtualne (np. VLAN, VRF),
• kontrola dostępu do systemów zarządzania (OSS/BSS),
• monitoring, systemy wykrywania anomalii, firewalle.

Celem jest uniemożliwienie podsłuchu przez osoby trzecie, a także ograniczenie skutków kompromitacji pojedynczego komponentu. Jednak dla pytania „co widzi operator przy szyfrowaniu end‑to‑end w 5G” kluczowe jest co innego: wewnątrz tego zaufanego królestwa operator może swobodnie analizować ruch, o ile nie jest on dodatkowo szyfrowany przez aplikację.

Co 5G robi lepiej niż 4G, a gdzie wciąż widać zbyt wiele

Najczęściej podkreślana poprawa 5G wobec 4G to ochrona identyfikatora abonenta. W 4G stały identyfikator IMSI mógł być przechwytywany przez fałszywe stacje bazowe. W 5G wprowadzono mechanizm SUCI, czyli zaszyfrowanego identyfikatora SUPI. Pozwala to zminimalizować pasywne śledzenie abonenta tylko po jego identyfikatorze.

Po stronie słabych punktów nadal pozostaje:

• lokalizacja – sama informacja, z którą komórką łączy się telefon, zdradza, gdzie mniej więcej się znajduje,
• wzorce ruchu – częstotliwość, pora dnia, wielkość pakietów, kierunki połączeń,
• metadane sesji – adresy IP, porty, domeny (chyba że dodatkowo ukryte, np. przez DoH/DoT, ECH w TLS),
• brak ochrony na poziomie samej aplikacji, jeśli ta nie korzysta z E2E.

Z perspektywy prywatności ważne jest, że 5G poprawia bezpieczeństwo techniczne sieci, ale nie eliminuje możliwości śledzenia użytkowników przez operatora i podmioty z nim współpracujące, ani nie zabezpiecza treści danych przed wszystkimi podmiotami. Rolę tę musi przejąć szyfrowanie end‑to‑end w warstwie aplikacji.

Czym jest prawdziwe szyfrowanie end‑to‑end i skąd się bierze

Definicja praktyczna, nie marketingowa

Szyfrowanie end‑to‑end oznacza, że klucz do odszyfrowania treści istnieje wyłącznie na urządzeniach końcowych – nadawcy i odbiorcy. Nie ma go ani u operatora 5G, ani u dostawcy chmury, ani u producenta aplikacji (w poprawnie zaprojektowanym systemie). Jeśli ktoś nie ma tego klucza, widzi tylko zaszyfrowany „sejf”, a nie jego zawartość.

Rozróżnienie jest proste, ale w praktyce często rozmywane:

• pseudoe2e – dane lecą szyfrowane do serwera aplikacji, tam są odszyfrowywane, obrabiane (np. filtrowanie treści, reklamy) i dopiero później znów szyfrowane do odbiorcy,
• prawdziwe E2E – serwer pełni rolę „przekaźnika” pakietów lub metadanych, ale nie ma technicznej możliwości zobaczenia treści.

W uproszczeniu: jeżeli producent komunikatora jest w stanie „odzyskać” Twoje wiadomości po stronie serwera, to nie jest to end‑to‑end w sensie kryptograficznym – choćby marketing twierdził inaczej.

Skąd biorą się klucze w E2E

Największe zamieszanie dotyczy tego, gdzie powstają i kto kontroluje klucze. Są trzy główne modele:

• klucze generowane lokalnie na urządzeniu – aplikacja tworzy parę kluczy (np. RSA, Curve25519), klucz prywatny nigdy nie opuszcza telefonu; to fundament większości komunikatorów E2E,
• klucze pochodzące z hasła użytkownika – np. szyfrowanie kopii zapasowych, gdzie klucz jest wyprowadzany z hasła głównego przy użyciu KDF (Argon2, scrypt, PBKDF2),
• klucze sprzętowe – generowane i przechowywane w bezpiecznym elemencie (Secure Enclave, TEE, eSIM/USIM z dodatkowymi funkcjami), do których system ma ograniczony dostęp.

Klucz wspólny pomiędzy dwoma użytkownikami jest ustalany przez protokoły wymiany, np. Diffie‑Hellmana na krzywych eliptycznych (ECDH). Operator 5G nie bierze w tym udziału – z jego punktu widzenia cała wymiana to zwykłe pakiety IP z losową treścią.

Protokół protokołowi nierówny – Signal, TLS i spółka

Gdy mówi się o E2E w komunikatorach, zwykle chodzi o rodzinę protokołów opartych na Signal Protocol. Ich cechy są istotne także z perspektywy sieci 5G:

• podwójne ratchety – klucze są stale zmieniane (tzw. perfect forward secrecy), więc przechwycenie jednego klucza nie odsłoni całej historii,
• tożsamość kryptograficzna – każdy użytkownik ma stały klucz publiczny, którego odcisk palca można porównać offline (kod QR, fraza bezpieczeństwa),
• brak konieczności centralnego przechowywania kluczy prywatnych – serwer nie ma dostępu do treści, choć zwykle zna metadane (z kim, kiedy, z jakiego IP).

Z drugiej strony mamy TLS, który też bywa nazywany E2E, ale jego model jest inny: domyślnie klucz serwera jest kontrolowany przez operatora usługi (właściciela domeny). Ruch klient–serwer jest szyfrowany, ale sam serwer widzi pełną treść. To znakomite zabezpieczenie przed podsłuchem na trasie, lecz nie chroni przed samym dostawcą usługi.

Rola systemu operacyjnego i sprzętu

E2E nie istnieje w próżni – opiera się na zaufaniu do urządzenia. Jeśli system operacyjny jest zainfekowany malwarem, żadne szyfrowanie nie pomoże, bo złośliwe oprogramowanie może przechwycić dane przed zaszyfrowaniem lub po odszyfrowaniu.

Dlatego producenci telefonów i OS‑ów inwestują w:

• TEE (Trusted Execution Environment) i bezpieczne enklawy, które przechowują klucze i wykonują operacje kryptograficzne w odseparowanym środowisku,
• bezpieczny rozruch (secure boot), aby uniemożliwić podmianę systemu na zmodyfikowany,
• szyfrowanie pamięci i magazynów kluczy (KeyStore, Keychain),
• polityki uprawnień dla aplikacji, by ograniczyć, kto może sięgnąć do wrażliwych danych.

Wszystko po to, żeby „sejf” z naszej analogii nie był z cienkiej blachy. Jeśli urządzenie jest kompromitowane, operator 5G nadal nie widzi treści, ale atakujący może je podglądać na samym końcu łańcucha – na ekranie i w pamięci telefonu.

Jak aplikacje „doklejają się” do 5G

Dla aplikacji z E2E sieć 5G jest „przezroczystym” transportem IP. Komunikator czy klient VPN korzysta zazwyczaj z:

• standardowego stosu TCP/UDP telefonu,
• adresów IP przydzielonych przez sieć 5G (PDU Session, zwykle przez UPF),
• czasem z APN‑ów specjalnych (np. dla firmowego VPN), choć to rzadziej w segmentach masowych.

Sam fakt, że ruch przechodzi przez sieć 5G, a nie Wi‑Fi, nie zmienia zasad działania E2E. Zmienia się natomiast to, kto widzi metadane. Gdy korzystasz z Wi‑Fi w kawiarni – operator 5G nie widzi ruchu, ale widzi go właściciel Wi‑Fi i jego dostawca internetu. Gdy korzystasz z 5G – sytuacja się odwraca.

Co jest faktycznie ukryte przed operatorem przy E2E w 5G

Treść wiadomości, rozmów i plików

Pierwszy i najbardziej oczywisty poziom to sama treść danych użytkownika. Jeśli komunikator, wideokonferencja lub aplikacja do plików stosuje poprawnie zaimplementowane E2E:

• operator 5G nie widzi treści wiadomości tekstowych,
• nie jest w stanie podsłuchać dźwięku ani obrazu z połączenia głosowego czy wideo,
• nie podejrzy zawartości przesyłanych plików, dokumentów, zdjęć.

Na poziomie pakietów IP widać tylko „szum” kryptograficzny – ciągi bajtów wyglądające losowo. Analizując je, można próbować zgadnąć rodzaj ruchu (np. strumieniowanie, krótkie wiadomości), ale nie da się odtworzyć słów, obrazu czy tekstu dokumentu.

Dane w spoczynku u dostawcy usługi

Drugi aspekt to dane przechowywane na serwerach aplikacji. Jeśli komunikator E2E przechowuje historię wiadomości w chmurze, robi to w postaci zaszyfrowanej kluczami, które są znane wyłącznie urządzeniom końcowym. Operator 5G nie ma do tej chmury dostępu w ogóle, ale nawet gdyby go dostał (np. w wyniku przejęcia serwera), nadal zobaczy tylko zaszyfrowane bloki.

Podobnie z szyfrowaniem dokumentów w chmurze (tzw. client‑side encryption). Operator 5G może widzieć, że wysyłasz duży plik do danej usługi, lecz nie jest w stanie:

• uzyskać zawartości tego pliku,
• łatwo określić typ danych (poza wielkością i tempem transferu),
• modyfikować pliku w sposób niewykrywalny (integralność jest chroniona kryptograficznie).

Fragmenty protokołów aplikacyjnych osłonięte przez „warstwę w warstwie”

Ciekawym obszarem są sytuacje, w których kilka poziomów szyfrowania nachodzi na siebie. Przykład:

• komunikator używa E2E do każdej wiadomości,
• całość ruchu jest dodatkowo „owinięta” w TLS,
• sieć 5G szyfruje łącze radiowe.

W takim układzie operator 5G widzi TLS (nagłówki, SNI albo ECH w nowszym TLS 1.3), ale:

• nie widzi wewnętrznego protokołu komunikatora (np. struktur wiadomości, pól opisujących reakcje, edycje, potwierdzenia),
• nie może „przebić się” przez TLS do wnętrza, żeby podejrzeć, jak dokładnie aplikacja przesyła klucze sesyjne,
• nie próbuje (zwykle) terminować TLS – to zadanie serwerów aplikacji.

Dzięki temu nawet gdyby operator chciał wdrożyć głęboką inspekcję pakietów (DPI), zatrzyma się na zewnętrznej warstwie TLS, i nie zobaczy „drugiego sejfu” z E2E w środku.

Czego nie da się łatwo zrekonstruować z metadanych

Metadane bywają groźne, ale mają też naturalne ograniczenia. Operator 5G, analizując sam kształt ruchu, ma wyzwanie przypominające próbę zgadnięcia treści książki tylko po jej wadze i formacie:

• może oszacować, że korzystasz intensywnie z komunikatora, ale nie odtworzy dokładnej rozmowy,
• może domyślać się, że łączysz się z serwerami konkretnej usługi (np. domena, zakres IP), ale nie wie, jakie konkretnie dane wewnątrz aplikacji przesyłasz,
• może znać długość i częstotliwość sesji VoIP, lecz nie przetworzy ich na słowa (brak dostępu do strumienia audio po dekodowaniu).

Zdarzają się bardziej zaawansowane ataki, np. analiza ruchu bocznego (traffic analysis) próbująca zgadywać akcje użytkownika po charakterystyce pakietów. Są to jednak techniki heurystyczne, podatne na błędy i wciąż nie dają pełnego wglądu w treść.

Granice widoczności operatora – gdzie E2E „przecina” jego możliwości

Patrząc warstwowo, można narysować prostą linię podziału:

• powyżej tej linii – warstwa aplikacji z E2E, treść i wewnętrzna logika protokołów są niewidoczne,
• poniżej – warstwa transportu i sieci (IP, TCP/UDP, 5G NAS/RRC), gdzie operator ma pełny wgląd w to, co sam zestawia i zarządza.

Operator 5G:

• widzi kto z kim się łączy na poziomie IP (chyba że używany jest dodatkowo VPN lub sieć anonimowa),
• zna przybliżoną lokalizację urządzenia i historię przemieszczania,
• zna wielkość i czas trwania sesji,
• czasem zna też nazwę domeny (SNI w TLS, zapytania DNS, jeśli nie są szyfrowane).

Jednocześnie, jeśli aplikacja używa poprawnego E2E:

• nie widzi treści (payloadu),
• nie ma dostępu do kluczy używanych w tej aplikacji,
• nie może zmodyfikować danych bez wykrycia przez odbiorcę (integralność jest kryptograficznie chroniona).

Przykład: rozmowa głosowa w komunikatorze E2E przez 5G

Wyobraźmy sobie rozmowę dwojga osób przez komunikator, który stosuje E2E, w sieci 5G SA (standalone):

1. Telefon A nawiązuje połączenie z serwerem sygnalizacyjnym aplikacji – ruch idzie przez 5G, jest szyfrowany radiowo oraz TLS‑em.
2. Telefony A i B wymieniają klucze sesyjne (np. przy użyciu ECDH), serwer tylko przekazuje zaszyfrowane wiadomości sygnalizacyjne.
3. Strumień audio jest szyfrowany kluczem sesyjnym (np. SRTP z E2E) i wysyłany jako pakiety UDP.

Co w tym momencie widzi operator 5G?

• że z numeru X do adresu IP serwera komunikatora Y idzie intensywny strumień UDP przez kilkanaście minut,
• że w tym samym czasie inny numer (telefon B) też wysyła podobny strumień do Y,
• że oba telefony są w danych lokalizacjach (komórkach, sektorach).

Czego nie widzi?

• nie jest w stanie odsłuchać treści rozmowy,
• nie odtworzy informacji o tym, kto do kogo dzwoni w sensie tożsamości z książki adresowej komunikatora (zna tylko numery/MSISDN, karty SIM, ewentualne identyfikatory IP),
• nie może zmodyfikować pakietów audio tak, by podsłuch „wmontować” w strumień – każda ingerencja złamie integralność i zostanie wykryta (połączenie po prostu przestanie działać poprawnie).

Zastosowanie VPN i sieci anonimowych na 5G

Jak VPN zmienia obraz widziany przez operatora 5G

VPN na 5G to trochę jak dodatkowy, prywatny tunel puszczony w środku autostrady operatora. Samochody (pakiety) jadą tą samą drogą, przez te same bramki (stacje bazowe, rdzeń sieci), ale dla operatora wszystkie wyglądają podobnie – to tylko zaszyfrowane kapsuły lecące do jednego celu: serwera VPN.

Z perspektywy widoczności danych sytuacja wygląda wtedy tak:

• operator nadal widzi twój telefon (IMSI/SUPI, numer MSISDN, kartę SIM, lokalizację),
• widzi, że łączysz się z konkretnym serwerem VPN (IP, port, czas trwania sesji),
• nie widzi natomiast dokąd dalej ruch biegnie „za” VPN – odwiedzanych stron, usług, konkretnych serwerów aplikacji,
• nie ma dostępu do DNS‑ów obsługiwanych po stronie VPN (np. DNS‑over‑HTTPS w środku tunelu).

Jeśli dodatkowo w środku tunelu działa E2E (np. komunikator), powstaje kaskada szyfrowania:

• warstwa 5G szyfruje od telefonu do stacji bazowej,
• VPN szyfruje od telefonu do serwera VPN,
• E2E szyfruje od aplikacji do aplikacji (telefon ↔ telefon lub telefon ↔ kilka urządzeń).

Operator 5G widzi wtedy tylko „zewnętrzną puszkę” VPN. To trochę jak paczka w paczce: kurier wie, skąd dokąd idzie przesyłka, ale nie zna zawartości wewnętrznej koperty, bo sama w środku też jest zaklejona i zaszyfrowana.

VPN firmowy versus „komercyjny” a ślad w sieci 5G

VPN VPN‑owi nierówny. Gdy telefon korzysta z firmowego tunelu (np. do zasobów korporacyjnych), operator 5G często rozpoznaje to po:

• dedykowanym APN‑ie (np. vpn.firma.pl),
• ustalonych docelowych adresach IP (konkretne bramy korporacyjne),
• politykach QoS przypisanych do tej sesji (gwarantowane pasmo, priorytetyzacja).

Czyli wie: „ten użytkownik korzysta z firmowego dostępu zdalnego”, ale nadal nie zna treści ruchu wewnątrz tunelu IPsec/SSL. W wielu firmach to i tak duży plus, bo cała wrażliwa logika – CRM, ERP, poczta – jest osłonięta przed oczami operatora i potencjalnymi podsłuchami w sieci publicznej.

W przypadku komercyjnych VPN‑ów (aplikacje typu „privacy VPN”) operator zwykle widzi tylko:

• adresy IP należące do dostawcy VPN,
• intensywny, ciągły strumień zaszyfrowanego ruchu,
• informację, że użytkownik praktycznie cały ruch wypycha do jednej lokalizacji.

Czy to w pełni anonimizuje użytkownika? Nie. Operator nadal zna tożsamość abonenta, jego lokalizację i momenty aktywności. VPN tylko „ucina” mu widoczność dalszych skoków pakietów w sieci globalnej.

Sieci anonimowe (Tor i podobne) na 5G

Jeżeli do miksu dołożymy sieć anonimową, np. Tor, układ robi się jeszcze ciekawszy. Z punktu widzenia operatora 5G dzieje się wtedy coś takiego:

• telefon zestawia zwykłą sesję IP w 5G,
• na tym IP powstaje tunel do pierwszego węzła Tora (entry/guard node),
• dalsze przeskoki (middle, exit) dzieją się już poza infrastrukturą operatora.

Co z tego wynika dla E2E? Gdy aplikacja w środku korzysta z E2E, mamy trzy warstwy ochrony:

1. szyfrowanie 5G na odcinku radiowym,
2. szyfrowanie „cebulowe” Tora w drodze do wyjścia,
3. szyfrowanie end‑to‑end po stronie aplikacji (np. komunikator).

Operator widzi jedynie, że dany numer (lub karta SIM) łączy się z jednym z węzłów Tora i generuje dość specyficzny ruch (małe, stałe pakiety, dość równomierne tempo). Nie widzi jednak, co dzieje się dalej w sieci Tor, ani tym bardziej – jakie dokładnie wiadomości aplikacja przesyła. To jak patrzenie na drogę do dworca, ale nigdy nie wchodzenie do pociągu, który odjeżdża dalej.

Co z VoWiFi, tetheringiem i hotspotem z telefonu

Budując obraz widoczności danych, przydaje się jeszcze jedna perspektywa – kiedy telefon jest mostem dla innych urządzeń.

W trybie VoWiFi (rozmowy głosowe przez Wi‑Fi, ale rozliczane przez operatora komórkowego) część tego, co zwykle idzie przez 5G, wchodzi w tunel IPsec przez Wi‑Fi do rdzenia operatora. Jeśli jednocześnie działa E2E (np. dzwonisz komunikatorem, nie natywnym dialerem), operator komórkowy nadal dostaje tylko metadane sesji IPsec i 5G, a treść rozmowy pozostaje w kapsule E2E.

Gdy robisz hotspot z telefonu 5G dla laptopa:

• operator 5G widzi ruch jako pochodzący z twojego telefonu (bo to on ma adres IP/PDU Session),
• nie widzi natomiast, które urządzenia są za NAT‑em telefonu (laptop, tablet, konsola),
• jeżeli laptop korzysta z E2E (np. przeglądarka z HTTPS, komunikator), operator nie ma wglądu w treść tych sesji.

W praktyce oznacza to, że hotspot staje się „mini‑routerem” z punktu widzenia prywatności. Szyfrowanie end‑to‑end na urządzeniach za nim działa dokładnie tak samo, jak w każdej innej sieci, a 5G jest tylko pierwszym skokiem w łańcuchu.

Specjalne scenariusze 5G: sieci prywatne i slicing a E2E

5G wprowadza mechanizmy, których wcześniej w sieciach komórkowych praktycznie nie było na masową skalę: sieci prywatne (NPN – Non‑Public Networks) i slicing (wirtualne wycinki sieci dla różnych usług). Dla E2E oznacza to inne środowisko, ale nie inne zasady kryptografii.

W prywatnej sieci 5G, np. na terenie fabryki:

• operator infrastruktury (czasem to firma, czasem operator publiczny w roli outsourcera) ma bardzo szeroką widoczność – od radia po rdzeń,
• urządzenia IoT i terminale często rozmawiają z lokalnymi serwerami (MEC) – ruch nawet nie wychodzi do internetu,
• jeżeli jednak urządzenia stosują E2E (np. maszyna szyfruje dane telemetryczne kluczem znanym tylko aplikacji analitycznej), operator prywatnej sieci nadal widzi jedynie zaszyfrowane payloady.

W slicing‑u sytuacja jest podobna: w jednym „plastrze” jadą np. krytyczne usługi przemysłowe, w drugim – rozrywka, w trzecim – aplikacje medyczne. Operator sieci może:

• rozdzielać zasoby i priorytety (QoS, pasmo, opóźnienia),
• monitorować wydajność i błędy w każdym slice osobno,
• zbierać metadane na poziomie ruchu IP w tym konkretnym wycinku.

Ale jeżeli w slice usług medycznych aplikacje włączą E2E dla dokumentacji pacjentów, to nawet administrator tego slice’u nie zobaczy treści badań, opisów wizyt czy wyników – tylko wolumeny zaszyfrowanych danych między punktami końcowymi.

E2E a usługi oparte na lokalizacji w 5G

Szyfrowanie end‑to‑end nie zmienia jednej rzeczy: 5G z natury jest technologią świadomą lokalizacji. Żeby zarządzać zasobami radiowymi i przekazywać połączenia między komórkami, sieć musi wiedzieć, gdzie mniej więcej jest urządzenie.

Dlatego nawet przy perfekcyjnie wdrożonym E2E operator nadal:

• zna przybliżone położenie telefonu (komórka, sektor, czasem z dokładnością do kilkudziesięciu metrów),
• potrafi odtworzyć historię przemieszczania (handovery między stacjami),
• może powiązać te informacje z momentami intensywnej aktywności danych lub rozmów.

Jeśli aplikacja wykorzystuje lokalizację (np. nawigacja, usługi „znajdź znajomych”), E2E chroni treść zapytań i odpowiedzi (konkretne adresy, współrzędne przesyłane wewnątrz komunikatora), ale sama obecność telefonu w danym miejscu nadal jest widoczna dla sieci. To trochę jak kurtyna w oknie: sąsiad nie wie, co robisz w środku pokoju, ale widzi, w którym domu i na którym piętrze się zapaliło światło.

Gdzie kończy się rola operatora, a zaczyna odpowiedzialność użytkownika

Szyfrowanie warstw 5G i E2E w aplikacjach tworzą razem całkiem solidny układ zabezpieczeń, jednak to, co dzieje się na końcówkach, zwykle zależy od użytkownika i twórców aplikacji. Kilka typowych „dziur” nie ma nic wspólnego z tym, czy dane lecą przez 4G, 5G czy Wi‑Fi:

• zainstalowane złośliwe aplikacje, które mają dostęp do powiadomień lub zawartości ekranu,
• kopie zapasowe w chmurze bez E2E, gdzie operator 5G co prawda nic nie widzi, ale dostawca chmury – już tak,
• udostępnianie telefonu odblokowanego (np. dziecku) – E2E nie pomoże, jeśli ktoś patrzy po prostu na ekran.

Można to porównać do zamka w drzwiach i rolety w oknie. Operator 5G i kryptografia troszczą się o to, żeby nikt nie otworzył drzwi po drodze ani nie zaglądał przez szybę. Ale jeśli zostawisz klucz w zamku od zewnątrz, cała ta infrastruktura traci sens. W świecie cyfrowym tym „kluczem” są: ustawienia prywatności, świadome korzystanie z aplikacji i dbałość o bezpieczeństwo samego urządzenia.

Najważniejsze punkty

• Szyfrowanie end‑to‑end chroni treść danych przed wszystkimi pośrednikami – także operatorem 5G i dostawcą chmury – podczas gdy „zwykłe” szyfrowanie transmisji zabezpiecza dane jedynie na odcinku kontrolowanym przez ten podmiot, który je szyfruje.
• Rozbudowana architektura 5G (MEC, NFV, slice’y, masowe IoT, M2M) zwiększa liczbę punktów potencjalnego ataku, więc rośnie potrzeba niezależnego szyfrowania E2E zamiast ślepego zaufania całej ścieżce sieciowej.
• 5G faktycznie poprawia bezpieczeństwo względem 4G (m.in. lepsza ochrona identyfikatora abonenta, uwierzytelnianie, szyfrowanie sygnalizacji), ale nie rozwiązuje problemów bezpieczeństwa na poziomie aplikacji, takich jak błędne konfiguracje, słabe logowanie czy brak szyfrowania danych w chmurze.
• Marketingowe hasło „5G jest z natury bezpieczne” jest uproszczeniem: nawet przy bardzo dobrze zabezpieczonej sieci operatora komunikator bez E2E wciąż pozostaje podatny na wgląd dostawcy usługi i wycieki z jego infrastruktury.
• Perspektywa użytkownika smartfona koncentruje się na prywatności komunikacji (komunikatory z E2E, HTTPS, VPN), podczas gdy dla firm kluczowe są kwestie odpowiedzialności prawnej, ryzyka fizycznych szkód, sabotażu i szpiegostwa w złożonych środowiskach (prywatne 5G, OT/SCADA, chmury).

Bibliografia i źródła

• 3GPP TS 33.501: Security architecture and procedures for 5G system. 3rd Generation Partnership Project (3GPP) (2024) – Główna specyfikacja bezpieczeństwa 5G: AKA, szyfrowanie, integralność, SUCI/SUPI
• 3GPP TS 33.210: 3G security; Network Domain Security (NDS); IP network layer security. 3rd Generation Partnership Project (3GPP) – Opis IPsec i ochrony transportu między elementami sieci operatora
• 3GPP TS 33.501 Security aspects of 5G System (5GS) – Technical Report overview. European Telecommunications Standards Institute (ETSI) – Przegląd architektury bezpieczeństwa 5G i powiązań z innymi normami
• Recommendation ITU-T X.1036: Framework for creation, storage, distribution and enforcement of security policies. International Telecommunication Union (ITU) – Ramowe podejście do polityk bezpieczeństwa i segmentacji sieci
• NIST Special Publication 800-187: Guide to LTE Security. National Institute of Standards and Technology (NIST) (2017) – Analiza bezpieczeństwa LTE; tło do porównań z 5G
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. Internet Engineering Task Force (IETF) (2018) – Specyfikacja TLS 1.3 używanego do szyfrowania aplikacyjnego i E2E