Fra oversætteren og TL;DR
-
TL; DR:
Det ser ud til, at VoLTE viste sig at være endnu værre beskyttet end de første Wi-Fi-klienter med WEP. En udelukkende arkitektonisk fejlberegning, der giver dig mulighed for at XOR trafikken lidt og gendanne nøglen. Et angreb er muligt, hvis du er tæt på den, der ringer, og han foretager opkald ofte.
-
Tak for tippet og TL;DR
-
Forskere har lavet en app til at afgøre, om din transportør er sårbar, læs mere . Del resultaterne i kommentarerne, VoLTE er deaktiveret i min region på Megafon.
Om forfatteren
Matthew Grøn.
Jeg er kryptograf og professor ved Johns Hopkins University. Jeg har designet og analyseret kryptografiske systemer, der bruges i trådløse netværk, betalingssystemer og sikkerhedsplatforme for digitalt indhold. I min forskning ser jeg på forskellige måder at bruge kryptografi til at forbedre brugernes privatliv.
Det er et stykke tid siden, jeg har skrevet et indlægsformat , og det gjorde mig ked af det. Ikke fordi der ikke var angreb, men mest fordi der ikke var et angreb på noget udbredt nok til at få mig ud af forfatterblok.
Men i dag stødte jeg på kaldet ReVoLTE for protokoller, som jeg er særligt begejstret for at hacke, nemlig mobilnetværk (voice over) LTE-protokoller. Jeg er begejstret for disse særlige protokoller – og dette nye angreb – fordi det er meget sjældent at se faktiske mobilnetværksprotokoller og implementeringer blive hacket. Hovedsageligt fordi disse standarder blev udviklet i røgfyldte rum og dokumenteret i 12000 sider lange dokumenter, som ikke alle forskere kan håndtere. Desuden tvinger implementeringen af disse angreb forskere til at bruge komplekse radioprotokoller.
Således kan alvorlige kryptografiske sårbarheder spredes over hele verden, måske kun for at blive udnyttet af regeringer, før nogen forsker lægger mærke til det. Men fra tid til anden er der undtagelser, og dagens angreb er et af dem.
Forfattere Bidragydere: David Rupprecht, Katharina Kohls, Thorsten Holz og Christina Pöpper fra Ruhr-University Bochum og New York University Abu Dhabi. Dette er et godt angreb for at geninstallere nøglen i den stemmeprotokol, du sandsynligvis allerede bruger (forudsat at du er fra en ældre generation, der stadig foretager telefonopkald ved hjælp af en mobiltelefon).
Til at begynde med en kort historisk udflugt.
Hvad er LTE og VoLTE?
Grundlaget for vores moderne standarder for mobiltelefoni blev lagt i Europa tilbage i 80'erne af standarden (Globalt system for mobilkommunikation). GSM var den første store digitale mobiltelefonistandard, som introducerede en række revolutionerende funktioner, som f.eks. for at beskytte telefonopkald. Tidlig GSM blev designet primært til talekommunikation, selvom penge kunne være .
Efterhånden som datatransmission blev vigtigere i mobilkommunikation, blev Long Term Evolution (LTE) standarder udviklet for at strømline denne type kommunikation. LTE er baseret på en gruppe af ældre standarder såsom GSM, и og er designet til at øge dataudvekslingshastigheden. Der er meget branding og men TL;DR er, at LTE er et datatransmissionssystem, der fungerer som en bro mellem ældre pakkedataprotokoller og fremtidige cellulære datateknologier .
Naturligvis fortæller historien os, at når der er nok (IP) båndbredde tilgængelig, vil begreber som "stemme" og "data" begynde at sløres. Det samme gælder moderne cellulære protokoller. For at gøre denne overgang glattere, definerer LTE-standarder (VoLTE), som er en IP-standard til at føre taleopkald direkte over dataplanet på et LTE-system, der helt omgår opkaldsdelen af det cellulære netværk. Som med standard ,VoLTE-opkald kan afsluttes af mobiloperatøren og tilsluttes det almindelige telefonnetværk. Eller (som det bliver mere og mere almindeligt) de direkte fra en mobilklient til en anden, og endda mellem forskellige udbydere.
Som standard VoIP er VoLTE baseret på to populære IP-baserede protokoller: Session Initiation Protocol ( – SIP) til opkaldsopsætning og realtidstransportprotokol (, som burde hedde RTTP, men faktisk kaldes RTP) til behandling af stemmedata. VoLTE tilføjer også nogle ekstra båndbreddeoptimeringer, såsom header-komprimering.
Okay, hvad har det med kryptering at gøre?
LTE, ligesom , har et standardsæt af kryptografiske protokoller til kryptering af pakker, når de transmitteres trådløst. De er hovedsageligt designet til at beskytte dine data, når de bevæger sig mellem telefonen (kaldet brugerudstyret eller UE) og mobiltårnet (eller hvor som helst din udbyder beslutter at afbryde forbindelsen). Dette skyldes, at mobiludbydere ser eksterne aflytningsenheder som fjender. Jamen selvfølgelig.
(Men det faktum, at VoLTE-forbindelser kan opstå direkte mellem klienter på forskellige udbydernetværk, betyder, at selve VoLTE-protokollen har nogle ekstra og valgfri krypteringsprotokoller, som kan forekomme på højere netværkslag. Dette er ikke relevant for den aktuelle artikel, bortset fra faktum, at de kan ødelægge alt (vi taler om dem kort næste gang).
Historisk set har kryptering i GSM været : dårligt , protokoller, hvor kun telefonen blev godkendt til tårnet (hvilket betyder, at en angriber kunne efterligne tårnet, hvilket ) og så videre. LTE korrigerede mange af de åbenlyse fejl, mens de bibeholdt meget af den samme struktur.
Lad os starte med selve kryptering. Hvis man antager, at nøgleoprettelse allerede er sket - og det taler vi om om et minut - så krypteres hver pakke data ved hjælp af strømkryptering ved hjælp af noget, der hedder "EEA" (som i praksis kan implementeres ved hjælp af ting som AES ). I det væsentlige er krypteringsmekanismen her som nedenfor:
Hovedkrypteringsalgoritmen for VoLTE-pakker (kilde: ). EEA er en chiffer, "COUNT" er en 32-bit tæller, "BEARER" er en unik sessionsidentifikator, der adskiller VoLTE-forbindelser fra almindelig internettrafik. "RETNING" angiver i hvilken retning trafikken flyder - fra UE til tårnet eller omvendt.
Da selve krypteringsalgoritmen (EEA) kan implementeres ved hjælp af en stærk chiffer som AES, er det usandsynligt, at der vil være noget direkte angreb på selve chifferen som denne . Det er dog klart, at selv med en stærk chiffer er denne krypteringsordning en fantastisk måde at skyde sig selv i foden på.
Især: LTE-standarden bruger en (uautentificeret) stream-chiffer med en tilstand, der vil være ekstremt sårbar, hvis tælleren - og andre input som "bærer" og "retning" - nogensinde genbruges. I moderne sprogbrug er betegnelsen for dette koncept "nonce-genbrugsangreb", men de potentielle risici her er ikke noget moderne. De er berømte og ældgamle og går tilbage til glam metal-tiden og endda disco.
Angreb på ikke-genbrug i CTR-tilstand eksisterede, selv da Poison blev kendt
For at være retfærdig siger LTE-standarderne: "Genbrug venligst ikke disse målere." Men LTE-standarder er omkring 7000 sider lange, og under alle omstændigheder er det som at bede børn om ikke at lege med en pistol. Det vil de uundgåeligt, og forfærdelige ting vil ske. Affyringspistolen i dette tilfælde er et keystream-genbrugsangreb, hvor to forskellige fortrolige meddelelser XOR de samme keystream-bytes. Det er kendt, at dette .
Hvad er ReVoLTE?
ReVoLTE-angrebet viser, at dette meget sårbare krypteringsdesign i praksis misbruges af hardware fra den virkelige verden. Specifikt analyserer forfatterne rigtige VoLTE-opkald foretaget ved hjælp af kommercielt udstyr og viser, at de kan bruge noget, der kaldes et "nøglegeninstallationsangreb." (Meget ære for at finde dette problem går til (Raza & Lu), som var de første til at påpege den potentielle sårbarhed. Men ReVoLTE-forskning gør det til et praktisk angreb).
Lad mig kort vise dig essensen af angrebet, selvom du bør se og .
Man kan antage, at når først LTE etablerer en pakkedataforbindelse, bliver opgaven med voice over LTE blot et spørgsmål om at dirigere talepakker over den forbindelse sammen med al den øvrige trafik. Med andre ord vil VoLTE være et koncept, der kun eksisterer over [OSI-modeller – ca.]. Dette er ikke helt rigtigt.
Faktisk introducerer LTE-linklaget begrebet "bærer". Bærere er separate sessionsidentifikatorer, der adskiller forskellige typer pakketrafik. Almindelig internettrafik (din Twitter og Snapchat) går gennem én bærer. SIP-signalering til VoIP går gennem en anden, og taletrafikpakker behandles gennem en tredje. Jeg er ikke særlig vidende om LTE-radio og netværksroutingmekanismer, men jeg tror, det er gjort på denne måde, fordi LTE-netværk ønsker at håndhæve QoS-mekanismer (servicekvalitet), så forskellige pakkestrømme behandles på forskellige prioritetsniveauer: dvs. din andenrangs TCP-forbindelser til Facebook kan have en lavere prioritet end dine taleopkald i realtid.
Dette er generelt ikke et problem, men konsekvenserne er som følger. Nøgler til LTE-kryptering oprettes separat, hver gang en ny "bærer" installeres. Som udgangspunkt bør dette ske igen, hver gang du foretager et nyt telefonopkald. Dette vil resultere i, at en anden krypteringsnøgle bruges til hvert opkald, hvilket eliminerer muligheden for at genbruge den samme nøgle til at kryptere to forskellige sæt taleopkaldspakker. Faktisk siger LTE-standarden noget i retning af "du skal bruge en anden nøgle, hver gang du installerer en ny bærer til at håndtere et nyt telefonopkald." Men det betyder ikke, at dette rent faktisk sker.
Faktisk, i virkelige implementeringer, vil to forskellige opkald, der forekommer i umiddelbar nærhed, bruge den samme nøgle - på trods af at nye bærere af samme navn er konfigureret mellem dem. Den eneste praktiske ændring, der sker mellem disse opkald, er, at krypteringstælleren nulstilles. I litteraturen kaldes dette nogle gange . Man kan argumentere for, at dette i det væsentlige er en implementeringsfejl, selvom risiciene i dette tilfælde i høj grad ser ud til at stamme fra selve standarden.
I praksis resulterer dette angreb i genbrug af nøglestrøm, hvor angriberen kan få de krypterede pakker $inline$C_1 = M_1 oplus KS$inline$ og $inline$C_2 = M_2 oplus KS$inline$, hvilket muliggør beregning af $inline$ C_1 plus C_2 = M_1 plus M_2$inline$. Endnu bedre, hvis angriberen kender en af $inline$M_1$inline$ eller $inline$M_2$inline$, så kan han straks genvinde den anden. Dette giver ham et stærkt incitament finde ud af en af de to ukrypterede komponenter.
Dette bringer os til det komplette og mest effektive angrebsscenarie. Overvej en angriber, der kan opsnappe radiotrafik mellem en måltelefon og et mobiltårn, og som på en eller anden måde er så heldig at optage to forskellige opkald, hvor det andet sker umiddelbart efter det første. Forestil dig nu, at han på en eller anden måde kunne gætte det ukrypterede indhold af et af opkaldene. Med sådan et lykketræf vores angriber kan fuldt ud dekryptere det første opkald ved hjælp af en simpel XOR mellem de to sæt pakker.
Held har selvfølgelig intet med det at gøre. Da telefoner er designet til at modtage opkald, vil en angriber, der kan overhøre det første opkald, være i stand til at starte et andet opkald i det nøjagtige øjeblik, det første slutter. Dette andet opkald, hvis den samme krypteringsnøgle bruges igen med tælleren nulstillet, vil tillade de ukrypterede data at blive gendannet. Desuden, da vores angriber faktisk kontrollerer dataene under det andet opkald, kan han gendanne indholdet af det første opkald - takket være mange specifikt implementerede små ting, spiller på hans side.
Her er et billede af den generelle angrebsplan taget fra :
Angrebsoversigt fra . Dette skema forudsætter, at to forskellige opkald foretages med den samme tast. Angriberen styrer den passive sniffer (øverst til venstre) samt en anden telefon, med hvilken han kan foretage et andet opkald til offerets telefon.
Så virker angrebet virkelig?
På den ene side er dette virkelig hovedspørgsmålet til artiklen om ReVoLTE. Alle ovenstående ideer er gode i teorien, men de efterlader en masse spørgsmål. Såsom:
- Er det muligt (for akademiske forskere) faktisk at opsnappe en VoLTE-forbindelse?
- Nøgler rigtige LTE-systemer faktisk om?
- Kan du faktisk starte et andet opkald hurtigt og pålideligt nok til, at telefonen og tårnet kan genbruge nøglen?
- Selvom systemerne gennøkler, kan du faktisk kende det ukrypterede indhold af det andet opkald - i betragtning af at ting som codecs og omkodning fuldstændigt kan ændre (bit-for-bit) indholdet af det andet opkald, selvom du har adgang til "bits" "kommer du fra din angrebstelefon?
ReVoLTEs arbejde besvarer nogle af disse spørgsmål bekræftende. Forfatterne bruger en kommerciel software-rekonfigurerbar radiostream sniffer kaldet at opsnappe et VoLTE-opkald fra downlink-siden. (Jeg tror, at bare det at sætte sig ind i softwaren og få en nogenlunde idé om, hvordan det virker, tog måneder fra de stakkels kandidatstuderendes liv - hvilket er typisk for denne form for akademisk forskning).
Forskerne fandt ud af, at for at genbruge nøgler skulle fungere, skulle det andet opkald ske hurtigt nok efter det første sluttede, men ikke for hurtigt - omkring ti sekunder for de operatører, de eksperimenterede med. Heldigvis er det lige meget, om brugeren besvarer opkaldet inden for denne tid – ”ringen” dvs. Selve SIP-forbindelsen tvinger operatøren til at genbruge den samme nøgle.
Mange af de mest elendige problemer drejer sig således om problem (4) - modtagelse af bits af det ukrypterede indhold af et opkald initieret af en angriber. Dette skyldes, at der kan ske meget med dit indhold, når det bevæger sig fra angriberens telefon til offerets telefon over mobilnetværket. For eksempel sådanne beskidte tricks som omkodning af en kodet lydstrøm, som efterlader lyden den samme, men fuldstændig ændrer dens binære repræsentation. LTE-netværk bruger også RTP-header-komprimering, hvilket kan ændre meget af RTP-pakken betydeligt.
Endelig skal de pakker, som angriberen sender, være nogenlunde på linje med de pakker, der blev sendt under det første telefonopkald. Dette kan være problematisk, fordi ændring af stilheden under et telefonopkald resulterer i kortere beskeder (alias komfortstøj), som måske ikke passer godt til det oprindelige opkald.
Det er værd at læse i detaljer. Den adresserer mange af ovenstående problemer - især fandt forfatterne ud af, at nogle codecs ikke er omkodet, og at cirka 89 % af målopkaldets binære repræsentation kan gendannes. Dette gælder for mindst to europæiske operatører, der blev testet.
Dette er en overraskende høj succesrate, og ærlig talt meget højere, end jeg forventede, da jeg begyndte at arbejde på dette dokument.
Så hvad kan vi gøre for at rette op på det?
Det umiddelbare svar på dette spørgsmål er meget enkelt: da essensen af sårbarheden er et nøglegenbrug (geninstallation) angreb, skal du blot løse problemet. Sørg for at få en ny nøgle for hvert telefonopkald, og lad aldrig pakketælleren nulstille tælleren med den samme tast. Problem løst!
Eller måske ikke. Dette vil kræve opgradering af en masse udstyr, og ærligt talt er sådan en rettelse i sig selv ikke super pålidelig. Det ville være rart, hvis standarder kunne finde en mere sikker måde at implementere deres krypteringstilstande på, som ikke som standard er katastrofalt sårbare over for sådanne nøglegenbrugsproblemer.
En mulig mulighed er at bruge . Dette kan være for dyrt for noget nuværende hardware, men det er bestemt et område, designere bør tænke på i fremtiden, især da 5G-standarder er ved at overtage verden.
Denne nye undersøgelse rejser også det generelle spørgsmål om hvorfor , hvoraf mange bruger meget lignende design og protokoller. Når du står over for problemet med at geninstallere den samme nøgle på tværs af flere udbredte protokoller som WPA2, tror du så ikke, det er på tide at gøre dine specifikationer og testprocedurer mere robuste? Stop med at behandle standardimplementere som betænksomme partnere, der er opmærksomme på dine advarsler. Behandl dem som (utilsigtede) modstandere, der uundgåeligt kommer til at tage fejl.
Eller alternativt kan vi gøre, hvad virksomheder som Facebook og Apple i stigende grad gør: få taleopkaldskryptering til at ske på et højere niveau af OSI-netværksstakken uden at være afhængig af producenter af mobiludstyr. Vi kunne endda presse på for end-to-end-kryptering af stemmeopkald, som WhatsApp gør med Signal og FaceTime, forudsat at den amerikanske regering bare stopper . Så (med undtagelse af nogle metadata) ville mange af disse problemer simpelthen forsvinde. Denne løsning er især relevant i en verden, hvor .
Eller vi kan simpelthen gøre, hvad vores børn allerede har gjort: stoppe med at besvare de irriterende taleopkald.
Kilde: www.habr.com