Od tłumacza i TL;DR
TL;DR:
Wygląda na to, że VoLTE jest jeszcze gorzej zabezpieczone niż pierwsze klienty Wi-Fi z WEP. To wyłącznie błąd architektoniczny, który umożliwia nieco poXOR’ować ruch i odzyskać klucz. Atak jest możliwy, jeśli znajdujesz się blisko dzwoniącego, a ten często wykonuje połączenia.
Dziękuję za wskazówkę i TL;DR
Badacze stworzyli aplikację do określenia, czy twój operator jest podatny, szczegóły . Podzielcie się w komentarzach swoimi wynikami, w moim regionie na MegoFon VoLTE jest wyłączone.
O autorze
Matthew Green.
Jestem kryptografem i profesorem na Uniwersytecie Johnsa Hopkinsa. Opracowywałem i analizowałem systemy kryptograficzne używane w sieciach bezprzewodowych, systemach płatności i platformach ochrony treści cyfrowych. W swoich badaniach rozważam różne sposoby wykorzystania kryptografii w celu zwiększenia prywatności użytkowników.
Długo nie pisałem postu w formacie , co mnie martwiło. Nie dlatego, że nie było ataków, ale głównie dlatego, że nie było ataku na coś wystarczająco powszechnego, aby wyciągnąć mnie z kryzysu twórczego.
Ale dziś natknąłem się na nazywany ReVoLTE na protokoły, złamanie których szczególnie mnie cieszy, a mianowicie, protokoły sieci komórkowych (voice over) LTE. Ekscytują mnie te protokoły – i ten nowy atak – ponieważ bardzo rzadko można zaobserwować złamanie rzeczywistych protokołów i realizacji sieci komórkowych. Głównie dlatego, że te standardy zostały opracowane w zadymionych pokojach i sformułowane w 12000-stronicowych dokumentach, które nie każdy badacz może przebrnąć. Co więcej, realizacja tych ataków zmusza badaczy do korzystania z trudnych protokołów radiowych.
W ten sposób poważne luki kryptograficzne mogą rozprzestrzenić się na całym świecie i być może będą wykorzystywane tylko przez rządy, zanim jakiś badacz zwróci na nie uwagę. Ale od czasu do czasu zdarzają się wyjątki, a dzisiejszy atak to jeden z nich.
Autorzy : David Rupprecht, Katharina Kohls, Thorsten Holz i Christina Pöpper z Uniwersytetu Ruhry w Bochum i Uniwersytetu Nowojorskiego w Abu Zabi. To doskonały atak na reinstalację klucza w protokole głosowym, który prawdopodobnie już stosujesz (zakładając, że należysz do starszego pokolenia, które nadal wykonuje połączenia telefoniczne za pomocą telefonu komórkowego).
Na początek – krótka historyczna wprowadzająca.
Czym jest LTE i VoLTE?
Podstawy naszych nowoczesnych standardów telekomunikacyjnych zostały wprowadzone w Europie już w latach 80-tych przez standard (Globalny system komunikacji mobilnej). GSM był pierwszym podstawowym standardem cyfrowej telefonii komórkowej, który wprowadził szereg rewolucyjnych funkcji, w tym wykorzystanie do zabezpieczania połączeń telefonicznych. Wczesny GSM został stworzony przede wszystkim do komunikacji głosowej, chociaż za dodatkową opłatą można było .
Wraz z rosnącym znaczeniem przesyłania danych w telekomunikacji opracowano standardy Long Term Evolution (LTE), aby ułatwić ten typ komunikacji. LTE bazuje na grupie starszych standardów, takich jak GSM, i i ma na celu zwiększenie prędkości transferu danych. W tej dziedzinie jest wiele brandingu i , ale TL;DR jest taki, że LTE to system przesyłania danych, który stanowi most pomiędzy starymi protokołami przesyłania pakietów a przyszłymi technologiami telekomunikacji komórkowej. .
Oczywiście historia mówi nam, że jak tylko dostępna będzie wystarczająca (IP) przepustowość, takie pojęcia jak „głos” i „dane” zaczną się zacierać. To samo dotyczy współczesnych protokołów telekomunikacyjnych. Aby to przejście było bardziej płynne, standardy LTE określają (VoLTE), który jest standardem IP do przesyłania połączeń głosowych bezpośrednio przez płaszczyznę przesyłania danych systemu LTE, całkowicie omijając przełączaną część sieci komórkowej. Podobnie jak w przypadku standardowych , połączenia VoLTE mogą być terminowane przez operatora komórkowego i łączone z klasyczną siecią telefoniczną. Lub (co staje się coraz bardziej powszechnym zjawiskiem) mogą być bezpośrednio od jednego klienta komórkowego do drugiego, a nawet między różnymi dostawcami.
Tak jak standardowa VoIP, VoLTE jest oparta na dwóch popularnych protokołach IP: protokole inicjowania sesji ( – SIP) do nawiązywania połączenia i protokole transportu w czasie rzeczywistym (, który powinien nazywać się RTTP, ale w rzeczywistości nazywa się RTP) do przetwarzania danych głosowych. VoLTE dodaje również pewne dodatkowe optymalizacje pasma, takie jak kompresja nagłówków.
Dobrze, jakie to ma znaczenie dla szyfrowania?
LTE, podobnie jak , ma standardowy zestaw protokołów kryptograficznych do szyfrowania pakietów podczas ich przesyłania w sieci. Mają one na celu głównie ochronę twoich danych podczas ich transportu między telefonem (nazywanym „sprzętem użytkownika”, czyli UE) a wieżą komórkową (lub gdziekolwiek twój dostawca zdecyduje się zakończyć połączenie). Dzieje się tak, ponieważ dostawcy usług komórkowych traktują zewnętrzne urządzenia podsłuchujące jako przeciwników. No, oczywiście.
(Jednak fakt, że połączenia VoLTE mogą zachodzić bezpośrednio między klientami w różnych sieciach dostawców, oznacza, że sam protokół VoLTE ma dodatkowe, opcjonalne protokoły szyfrowania, które mogą występować na wyższych poziomach sieci. Nie dotyczy to obecnego artykułu, z wyjątkiem tego, że mogą one wszystko zepsuć. Krótko omówimy je później).
Historycznie szyfrowanie w GSM miało : słabe , protokoły, w których tylko telefon autoryzował się na wieży (co oznacza, że intruz mógł podszyć się pod wieżę, generując ) i tak dalej. LTE naprawił wiele oczywistych błędów, zachowując jednak dużą część wcześniejszej struktury.
Zacznijmy od samego szyfrowania. Zakładając, że klucz już został utworzony – a o tym porozmawiamy za chwilę – każdy pakiet danych jest szyfrowany za pomocą trybu strumieniowego szyfrowania przy użyciu jakiegoś szyfru o nazwie „EEA” (który w praktyce może być realizowany przy użyciu takich rzeczy jak AES). W zasadzie mechanizm szyfrowania tutaj to , jak pokazano poniżej:
Główny algorytm szyfrowania pakietów VoLTE (źródło: ). EEA – szyfr, „COUNT” – 32-bitowy licznik, „BEARER” — unikalny identyfikator sesji, oddzielający połączenia VoLTE od zwykłego ruchu internetowego. „DIRECTION” wskazuje kierunek ruchu – od UE do stacji bazowej lub odwrotnie.
Ponieważ sam algorytm szyfrowania (EEA) może być realizowany przy użyciu silnego szyfru typu AES, mało prawdopodobne jest, aby istniał bezpośredni atak na sam szyfr, jak to . Jednak oczywiste jest, że nawet przy silnym szyfrowaniu ten schemat szyfrowania stanowi doskonały sposób na strzał w stopę.
W szczególności: w standardzie LTE używany jest (nieautoryzowany) strumieniowy szyfr w trybie, który będzie niezwykle podatny, jeśli licznik — oraz inne wejścia, takie jak „bearer” i „direction” — będą kiedykolwiek używane ponownie. W nowoczesnym języku termin na to pojęcie to „atak ponownego użycia nonce”, ale potencjalne zagrożenia nie są czymś nowym. Są to znane i odwieczne problemy, sięgające czasów glam metalu, a nawet disco.
Ataki na ponowne użycie nonce w trybie CTR istniały już wtedy, gdy Poison stały się znane
Słusznie mówiąc, w standardach LTE napisano: „Nie używajcie tych liczników ponownie, proszę”. Ale standardy LTE mają około 7000 stron, a w każdym razie to jak proszenie dzieci, aby nie bawiły się z pistoletem. Niezawodnie to zrobią, a straszne rzeczy się wydarzą. W tym przypadku strzelającym pistoletem jest atak z ponownym użyciem strumienia klucza, w którym dwa różne wiadomości poufne są XOR-owane tymi samymi bajtami strumienia klucza. Wiadomo, że to .
Czym jest ReVoLTE?
Atak ReVoLTE demonstruje, że w praktyce ta bardzo podatna konstrukcja szyfrowania jest niepoprawnie używana przez rzeczywisty sprzęt. W szczególności autorzy analizują rzeczywiste połączenia VoLTE, dokonane przy użyciu komercyjnego sprzętu, i pokazują, że mogą zastosować coś, co nazywa się „atak na ponowne ustawienie klucza”. (Ogromna zasługa znalezienia tego problemu należy do (Raza & Lu), którzy jako pierwsi wskazali na potencjalną podatność. Jednak badania ReVoLTE przekształcają ją w praktyczny atak.
Pozwól, że krótko przedstawię istotę ataku, chociaż warto, abyś również obejrzał .
Można przypuszczać, że w momencie, gdy LTE nawiązuje połączenie w pakietowej transmisji danych, zadanie przesyłania głosu przez LTE staje się jedynie kwestią routingu pakietów głosowych przez to połączenie, razem z całym Twoim pozostałym ruchem. Innymi słowy, VoLTE będzie koncepcją, która istnieje jedynie powyżej [modelu OSI – przykład itd.] Nie jest to do końca prawda.
Faktycznie, warstwa łącza LTE wprowadza pojęcie „bearer”. Bearer to oddzielne identyfikatory sesji, które rozdzielają różne rodzaje ruchu pakietowego. Zwykły ruch internetowy (Twój Twitter i Snapchat) przebiega przez jeden bearer. Signaling SIP dla VoIP idzie przez inny, a pakiety ruchu głosowego są przetwarzane na trzecim. Nie znam się na mechanizmach radiowych i routingu sieciowym LTE, ale przypuszczam, że jest to zrobione w ten sposób, ponieważ sieci LTE chcą zapewnić działanie mechanizmów QoS (jakości usług), aby różne strumienie pakietów były przetwarzane z różnymi poziomami priorytetu: tzn. Twoje drugorzędne połączenia TCP z Facebookiem mogą mieć niższy priorytet niż Twoje rozmowy głosowe w czasie rzeczywistym.
To w zasadzie nie jest problem, ale konsekwencje są następujące. Klucze do szyfrowania LTE są tworzone osobno za każdym razem, gdy nawiązywane jest nowe „bearer”. Zasadniczo powinno to mieć miejsce od nowa za każdym razem, gdy wykonujesz nowe połączenie telefoniczne. Spowoduje to, że dla każdego połączenia będzie używany inny klucz szyfrowania, co uniemożliwia ponowne użycie tego samego klucza do szyfrowania dwóch różnych zestawów pakietów połączeń głosowych. Faktycznie, standard LTE mówi coś w stylu „musisz używać różnych kluczy za każdym razem, gdy nawiążesz nowe bearer do przetwarzania nowego połączenia telefonicznego”. Ale to nie znaczy, że tak rzeczywiście się dzieje.
W rzeczywistości, w prawdziwych implementacjach dwa różne wywołania, które mają miejsce w bezpośredniej bliskości czasowej, będą używać tego samego klucza — mimo że pomiędzy nimi konfigurowane są nowe (o tej samej nazwie) bearer. Jedyną praktyczną zmianą, która zachodzi pomiędzy tymi wywołaniami, jest reset licznika szyfrowania do zera. W literaturze czasami nazywa się to . Można argumentować, że w zasadzie jest to błąd implementacji, chociaż w tym przypadku ryzyka, jak się wydaje, w znacznej mierze wynikają z samego standardu.
W praktyce ten atak prowadzi do ponownego wykorzystania strumienia kluczowego, gdzie napastnik może uzyskać zaszyfrowane pakiety $inline$C_1 = M_1 oplus KS$inline$ oraz $inline$C_2 = M_2 oplus KS$inline$, co umożliwia obliczenie $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Jeszcze lepiej, jeśli napastnik zna jeden z $inline$M_1$inline$ lub $inline$M_2$inline$, może natychmiast przywrócić drugi. Daje mu to silny bodziec do poznania jednego z dwóch niezaszyfrowanych komponentów.
To prowadzi nas do pełnego i najbardziej efektywnego scenariusza ataku. Rozważmy napastnika, który może przechwytywać ruch radiowy między docelowym telefonem a wieżą komórkową, i który w jakiś sprytny sposób «miał szczęście» zarejestrować dwa różne połączenia, gdzie drugie następuje właśnie po pierwszym. Teraz wyobraźmy sobie, że w jakiś sposób jest w stanie zgadnąć niezaszyfrowaną treść jednego z połączeń. W przypadku takiej szczęśliwej okoliczności nasz napastnik może całkowicie odszyfrować pierwsze połączenie, wykorzystując prosty XOR pomiędzy dwoma zestawami pakietów.
Oczywiście, szczęście nie ma tu nic do rzeczy. Ponieważ telefony są przeznaczone do odbierania połączeń, napastnik, który może podsłuchać pierwsze połączenie, będzie mógł zainicjować i drugie połączenie dokładnie w momencie, gdy zakończy się pierwsze. To drugie połączenie, w przypadku ponownego użycia tego samego klucza szyfrowania z licznikiem zresetowanym do zera, pozwoli na przywrócenie niezaszyfrowanych danych. Co więcej, ponieważ nasz napastnik faktycznie kontroluje dane podczas drugiego połączenia, może przywrócić treść pierwszego połączenia – dzięki wielu specyficznie zaimplementowanym szczegółom, które grają na jego korzyść.
Oto obraz ogólnego planu ataku, zainspirowany z :
Przegląd ataku z . Schemat ten zakłada, że występują dwa różne połączenia przy użyciu tego samego klucza. Atakujący kontroluje pasywny sniffer (w lewym górnym rogu) oraz drugi telefon, przy pomocy którego może wykonać drugie połączenie do telefonu ofiary.
Czy ten atak rzeczywiście działa?
Z jednej strony to rzeczywiście kluczowe pytanie dla artykułu o ReVoLTE. Teoretycznie wszystkie wymienione wcześniej pomysły są znakomite, ale pozostawiają wiele pytań, takich jak:
- Czy możliwe jest (dla naukowców akademickich) rzeczywiste przechwycenie połączenia VoLTE?
- Czy rzeczywiście istniejące systemy LTE ponownie ustalają klucze?
- Czy naprawdę możesz zainicjować drugie połączenie wystarczająco szybko i niezawodnie, aby telefon i wieża powtórnie wykorzystały klucz?
- Nawet jeśli systemy ponownie ustalają klucze, czy możesz naprawdę poznać niezaszyfrowaną treść drugiego połączenia – biorąc pod uwagę, że takie rzeczy, jak kodeki i re-kodowanie mogą całkowicie zmienić (bit po bicie) treść tego drugiego połączenia, nawet jeśli masz dostęp do „bitów” pochodzących z twojego atakującego telefonu?
Na niektóre z tych pytań praca ReVoLTE odpowiada twierdząco. Autorzy używają komercyjnego oprogramowania do przechwytywania strumienia radiowego nazwanego do przechwycenia połączenia VoLTE z kierunku zstępującego. (Myślę, że samo opanowanie oprogramowania i zrozumienie, jak to działa, zabrało miesiące życia biednym doktorantom – co jest typowe dla tego rodzaju badań akademickich).
Badacze odkryli, że aby wykorzystać ponownie klucz, drugie połączenie musi nastąpić wystarczająco szybko po zakończeniu pierwszego, ale nie za szybko – około dziesięciu sekund dla operatorów, z którymi eksperymentowali. Na szczęście nie ma znaczenia, czy użytkownik odbierze połączenie w tym czasie – „połączenie”, tj. sama komunikacja SIP, powoduje, że operator ponownie używa tego samego klucza.
Wiele z najgorszych problemów dotyczy problemu (4) – uzyskania bitów niezaszyfrowanej treści połączenia, zainicjowanego przez atakującego. Dzieje się tak, ponieważ z Twoją treścią może się wiele wydarzyć, gdy przechodzi ona od telefonu przestępcy do telefonu ofiary przez sieć komórkową. Na przykład można spotkać się z zjawiskiem ponownego kodowania zakodowanego strumienia audio, co pozostawia dźwięk bez zmian, ale całkowicie zmienia jego reprezentację binarną. W sieciach LTE stosuje się również kompresję nagłówków RTP, co może znacząco zmienić dużą część pakietu RTP.
Na koniec pakiety wysyłane przez atakującego muszą być zgrupowane w mniej więcej tę samą linię co pakiety, które zostały wysłane podczas pierwszego połączenia telefonicznego. Może to być problematyczne, ponieważ modyfikacja ciszy podczas rozmowy telefonicznej prowadzi do krótszych wiadomości (tzw. komfortowy szum), które mogą źle współgrać z oryginalnym połączeniem.
jest zdecydowanie warta przeczytania w całości. Porusza wiele z wymienionych problemów – w szczególności autorzy odkryli, że niektóre kodeki nie są ponownie kodowane oraz że około 89% binarnej reprezentacji docelowego połączenia może być odzyskane. Dotyczy to co najmniej dwóch europejskich operatorów, którzy zostali przetestowani.
To niesamowicie wysoki poziom sukcesu i, szczerze mówiąc, znacznie wyższy, niż się spodziewałem, gdy zaczynałem pracę nad tym dokumentem.
Co możemy zrobić, aby to naprawić?
Natychmiastowa odpowiedź na to pytanie jest bardzo prosta: ponieważ istotą podatności jest atak na ponowne użycie (reanstalację) klucza, po prostu rozwiąż ten problem. Upewnij się, że dla każdego połączenia telefonicznego uzyskuje się nowy klucz, i nigdy nie pozwól licznikom pakietów zresetować licznika do zera przy użyciu tego samego klucza. Problem rozwiązany!
A może jednak nie. Wymagałoby to modernizacji dużej ilości sprzętu, a szczerze mówiąc, taki fix sam w sobie nie jest super niezawodny. Dobrze byłoby, gdyby standardy znalazły bezpieczniejszy sposób realizacji swoich trybów szyfrowania, który nie byłby domyślnie katastrofalnie podatny na podobne problemy z ponownym używaniem kluczy.
Jednym z możliwych rozwiązań jest zastosowanie . Może to być zbyt kosztowne dla niektórego nowoczesnego sprzętu, ale z pewnością jest to kierunek, o którym projektanci powinni myśleć w przyszłości, szczególnie biorąc pod uwagę, że standardy 5G wkrótce opanują świat.
To nowe badanie podnosi również ogólne pytanie o to, dlaczego , z których wiele wykorzystuje bardzo podobne konstrukcje i protokoły. Gdy stajesz przed problemem reinstalacji tego samego klucza w kilku powszechnie stosowanych protokołach, takich jak WPA2, czy nie wydaje się, że nadszedł czas, aby uczynić swoje specyfikacje i procedury testowania bardziej niezawodnymi? Dość już traktować realizatorów standardów jak przemyślane partnerów, uważnych na Twoje ostrzeżenia. Traktuj ich jak (niezamierzonych) przeciwników, którzy nieuchronnie mają zamiar wprowadzić wszystko w błąd.
Alternatywnie, możemy zrobić to, co coraz częściej robią firmy takie jak Facebook i Apple: umożliwić szyfrowanie połączeń głosowych na wyższym poziomie stosu OSI, nie polegając na producentach sprzętu komórkowego. Możemy nawet promować szyfrowanie end-to-end w połączeniach głosowych, jak robią to WhatsApp z Signal i FaceTime, zakładając, że rząd USA po prostu przestanie . Wówczas (za wyjątkiem niektórych metadanych) wiele z tych problemów po prostu by zniknęło. To rozwiązanie jest szczególnie aktualne w świecie, w którym .
Możemy po prostu zrobić to, co już zrobiły nasze dzieci: przestać odpowiadać na te irytujące połączenia głosowe.
Źródło: habr.com
