Aanval van die week: stemoproepe in LTE (ReVoLTE)

Van die vertaler en TL;DR

  1. TL; DR:

    Dit blyk dat VoLTE selfs slegter beskerm is as die eerste Wi-Fi-kliënte met WEP. 'n Uitsluitlik argitektoniese misrekening wat jou toelaat om die verkeer 'n bietjie te XOR en die sleutel te herstel. ’n Aanval is moontlik as jy naby die oproeper is en hy maak gereeld oproepe.

  2. Dankie vir die wenk en TL;DR Klukonin

  3. Navorsers het 'n toepassing gemaak om te bepaal of jou diensverskaffer kwesbaar is, lees meer hier. Deel die resultate in die kommentaar, VoLTE is gedeaktiveer in my streek op Megafon.

Oor die skrywer

Matthew Groen.

Ek is 'n kriptograaf en professor aan die Johns Hopkins Universiteit. Ek het kriptografiese stelsels ontwerp en ontleed wat in draadlose netwerke, betalingstelsels en digitale inhoudsekuriteitsplatforms gebruik word. In my navorsing kyk ek na verskillende maniere om kriptografie te gebruik om gebruikersprivaatheid te verbeter.

Dit is 'n rukkie sedert ek 'n posformaat geskryf het "aanval van die week", en dit het my ontstel. Nie omdat daar nie aanvalle was nie, maar meestal omdat daar nie ’n aanval was op iets wat wyd genoeg gebruik is om my uit skrywersblok te kry nie.

Maar vandag het ek afgekom interessante aanval genoem ReVoLTE vir protokolle waaroor ek veral opgewonde is oor inbraak, naamlik sellulêre netwerk (voice over) LTE-protokolle. Ek is opgewonde oor hierdie spesifieke protokolle - en hierdie nuwe aanval - want dit is baie skaars om werklike sellulêre netwerkprotokolle en implementerings te sien wat gehack word. Hoofsaaklik omdat hierdie standaarde in rookgevulde kamers ontwikkel is en in dokumente van 12000 XNUMX bladsye gedokumenteer is wat nie elke navorser kan hanteer nie. Boonop dwing die implementering van hierdie aanvalle navorsers om komplekse radioprotokolle te gebruik.

Ernstige kriptografiese kwesbaarhede kan dus oor die hele wêreld versprei, miskien net om deur regerings uitgebuit te word, voordat enige navorser kennis neem. Maar van tyd tot tyd is daar uitsonderings, en vandag se aanval is een daarvan.

Skrywers aanvalleBydraers: David Rupprecht, Katharina Kohls, Thorsten Holz en Christina Pöpper van Ruhr-Universiteit Bochum en New York Universiteit Abu Dhabi. Dit is 'n goeie aanval om die sleutel in die stemprotokol wat jy waarskynlik reeds gebruik weer te installeer (met die veronderstelling dat jy van 'n ouer generasie is wat steeds telefoonoproepe maak met 'n selfoon).

Om mee te begin, 'n kort historiese uitstappie.

Wat is LTE en VoLTE?

Die basis van ons moderne sellulêre telefoniestandaarde is in die 80's deur die standaard in Europa gelê Globale stelsel vir selfoon (Globale stelsel vir mobiele kommunikasie). GSM was die eerste groot digitale sellulêre telefoniestandaard, wat 'n aantal revolusionêre kenmerke ingestel het, soos die gebruik enkripsie telefoonoproepe te beskerm. Vroeë GSM is hoofsaaklik ontwerp vir stemkommunikasie, hoewel geld kan wees ander data oordra.

Namate data-oordrag belangriker geword het in sellulêre kommunikasie, is Langtermyn Evolusie (LTE) standaarde ontwikkel om hierdie tipe kommunikasie te stroomlyn. LTE is gebaseer op 'n groep ouer standaarde soos GSM, EDGE и HSPA en is ontwerp om data-uitruilspoed te verhoog. Daar is baie handelsmerke en misleidend deur verkeerde benamingsmaar die TL;DR is dat LTE 'n data-oordragstelsel is wat dien as 'n brug tussen ouer pakkiedataprotokolle en toekomstige sellulêre datategnologie 5G.

Natuurlik vertel die geskiedenis ons dat sodra daar genoeg (IP) bandwydte beskikbaar is, konsepte soos "stem" en "data" sal begin vervaag. Dieselfde geld vir moderne sellulêre protokolle. Om hierdie oorgang gladder te maak, definieer LTE-standaarde Stem-oor-LTE (VoLTE), wat 'n IP-standaard is om stemoproepe direk oor die datavlak van 'n LTE-stelsel te dra, wat die inbelgedeelte van die sellulêre netwerk heeltemal omseil. Soos met standaard VoIP-oproepe,VoLTE-oproepe kan deur die sellulêre operateur beëindig word en aan die gewone telefoonnetwerk gekoppel word. Of (soos al hoe meer algemeen word) hulle herlei kan word direk van een sellulêre kliënt na 'n ander, en selfs tussen verskillende verskaffers.

Soos standaard VoIP, is VoLTE gebaseer op twee gewilde IP-gebaseerde protokolle: Session Initiation Protocol (Sessie-inisiasieprotokol - SIP) vir oproepopstelling en intydse vervoerprotokol (Intydse vervoerprotokol, wat RTTP genoem moet word, maar eintlik RTP genoem word) vir die verwerking van stemdata. VoLTE voeg ook 'n paar bykomende bandwydte-optimalisasies by, soos kopkompressie.

Goed, wat het dit met enkripsie te doen?

LTE, soos GSM, het 'n standaard stel kriptografiese protokolle vir die enkripteer van pakkies soos dit oor die lug versend word. Hulle is hoofsaaklik ontwerp om jou data te beskerm terwyl dit tussen die foon beweeg (genoem die gebruikertoerusting, of UE) en die selfoontoring (of waar ook al jou verskaffer besluit om die verbinding te beëindig). Dit is omdat sellulêre verskaffers eksterne afluistertoestelle as vyande beskou. Wel, natuurlik.

(Die feit dat VoLTE-verbindings egter direk tussen kliënte op verskillende verskaffernetwerke kan voorkom, beteken dat die VoLTE-protokol self 'n paar bykomende en opsionele enkripsieprotokolle het wat by hoër netwerklae kan voorkom. Dit is nie relevant vir die huidige artikel nie, behalwe die feit dat hulle kan alles verwoes (ons sal volgende kortliks daaroor praat).

Histories was enkripsie in GSM baie swak punte: sleg syfers, protokolle waarin slegs die foon aan die toring geverifieer is (wat beteken dat 'n aanvaller die toring kan naboots, wat "Stingray") en so aan. LTE het baie van die ooglopende foute reggestel terwyl baie van dieselfde struktuur gehandhaaf is.

Kom ons begin met enkripsie self. As ons aanvaar dat sleutelskepping reeds plaasgevind het - en ons sal oor 'n minuut daaroor praat - dan word elke pakkie data geïnkripteer met stroomenkripsie deur iets genaamd "EEA" te gebruik (wat in die praktyk geïmplementeer kan word deur dinge soos AES ). In wese is die enkripsiemeganisme hier Deurkliektemposoos hieronder:

Aanval van die week: stemoproepe in LTE (ReVoLTE)
Die belangrikste enkripsie-algoritme vir VoLTE-pakkies (bron: ReVoLTE). EEA is 'n syfer, "COUNT" is 'n 32-bis-teller, "BEARER" is 'n unieke sessie-identifiseerder wat VoLTE-verbindings van gewone internetverkeer skei. "RIGTING" dui aan in watter rigting die verkeer vloei - van die UE na die toring of andersom.

Aangesien die enkripsie-algoritme self (EEA) geïmplementeer kan word met 'n sterk syfer soos AES, is dit onwaarskynlik dat daar 'n direkte aanval op die syfer self soos hierdie sal wees gebeur het in die dae van GSM. Dit is egter duidelik dat selfs met 'n sterk syfer, hierdie enkripsieskema 'n goeie manier is om jouself in die voet te skiet.

In die besonder: die LTE-standaard gebruik 'n (ongeverifieerde) stroomsyfer met 'n modus wat uiters kwesbaar sal wees as die teller - en ander insette soos "draer" en "rigting" - ooit hergebruik word. In moderne spreektaal is die term vir hierdie konsep "nie-hergebruikaanval", maar die potensiële risiko's hier is nie iets moderns nie. Hulle is beroemd en oud en dateer uit die dae van glam metal en selfs disco.

Aanval van die week: stemoproepe in LTE (ReVoLTE)
Aanvalle op nie-hergebruik in CTR-modus het bestaan ​​selfs toe Poison bekend geword het

Om regverdig te wees, sê die LTE-standaarde: "Moet asseblief nie hierdie meters hergebruik nie." Maar die LTE-standaarde is ongeveer 7000 XNUMX bladsye lank, en in elk geval is dit soos om kinders te smeek om nie met 'n geweer te speel nie. Hulle sal onvermydelik, en verskriklike dinge sal gebeur. Die vuurwapen in hierdie geval is 'n sleutelstroom-hergebruikaanval, waarin twee verskillende vertroulike boodskappe XOF dieselfde sleutelstroomgrepe. Dit is bekend dat dit het 'n baie vernietigende uitwerking op die vertroulikheid van kommunikasie.

Wat is ReVoLTE?

Die ReVoLTE-aanval demonstreer dat hierdie baie kwesbare enkripsie-ontwerp in die praktyk deur werklike hardeware misbruik word. Spesifiek, die skrywers ontleed werklike VoLTE-oproepe wat gemaak word met kommersiële toerusting en wys dat hulle iets kan gebruik wat 'n "sleutelherinstallasie-aanval" genoem word. (Baie krediet vir die vind van hierdie probleem gaan aan Reise en Lu (Raza & Lu), wat die eerste was wat die potensiële kwesbaarheid uitgewys het. Maar ReVoLTE-navorsing verander dit in 'n praktiese aanval).

Kom ek wys jou kortliks die essensie van die aanval, alhoewel jy moet kyk en oorspronklike dokument.

Mens kan aanvaar dat sodra LTE 'n pakkiedataverbinding tot stand bring, die taak van stem-oor-LTE net 'n kwessie word om stempakkies oor daardie verbinding saam met al die res van jou verkeer te stuur. Met ander woorde, VoLTE sal 'n konsep wees wat net oor bestaan 2de vlak [OSI-modelle – ongeveer.]. Dit is nie heeltemal waar nie.

Trouens, die LTE-skakellaag stel die konsep van "draer" bekend. Draers is afsonderlike sessie-identifiseerders wat verskillende tipes pakkieverkeer skei. Gereelde internetverkeer (jou Twitter en Snapchat) gaan deur een draer. SIP-sein vir VoIP gaan deur 'n ander, en stemverkeerpakkette word deur 'n derde verwerk. Ek is nie baie kundig oor LTE-radio- en netwerkroeteringsmeganismes nie, maar ek glo dit word so gedoen omdat LTE-netwerke QoS (kwaliteit van diens)-meganismes wil afdwing sodat verskillende pakkiestrome op verskillende prioriteitsvlakke verwerk word: m.a.w. joune tweederangse TCP-verbindings met Facebook kan 'n laer prioriteit hê as jou intydse stemoproepe.

Dit is oor die algemeen nie 'n probleem nie, maar die gevolge is soos volg. Sleutels vir LTE-enkripsie word afsonderlik geskep elke keer as 'n nuwe "draer" geïnstalleer word. Basies moet dit weer gebeur elke keer as jy 'n nuwe telefoonoproep maak. Dit sal daartoe lei dat 'n ander enkripsiesleutel vir elke oproep gebruik word, wat die moontlikheid uitskakel om dieselfde sleutel te hergebruik om twee verskillende stelle stemoproeppakkies te enkripteer. Inderdaad, die LTE-standaard sê iets soos "jy moet 'n ander sleutel gebruik elke keer as jy 'n nuwe draer installeer om 'n nuwe telefoonoproep te hanteer." Maar dit beteken nie dat dit werklik gebeur nie.

Trouens, in werklike implementerings, sal twee verskillende oproepe wat in die nabyheid van die tyd plaasvind, dieselfde sleutel gebruik - ten spyte van die feit dat nuwe draers met dieselfde naam tussen hulle gekonfigureer is. Die enigste praktiese verandering wat tussen hierdie oproepe plaasvind, is dat die enkripsieteller na nul teruggestel word. In die literatuur word dit soms genoem sleutel herinstallasie aanval. Mens kan redeneer dat dit in wese 'n implementeringsfout is, hoewel die risiko's in hierdie geval grootliks uit die standaard self spruit.

In die praktyk lei hierdie aanval tot hergebruik van sleutelstroom, waar die aanvaller die geënkripteerde pakkies $inline$C_1 = M_1 oplus KS$inline$ en $inline$C_2 = M_2 oplus KS$inline$ kan verkry, wat die berekening van $inline$ moontlik maak. C_1 oplus C_2 = M_1 oplus M_2$inline$. Nog beter, as die aanvaller een van $inline$M_1$inline$ of $inline$M_2$inline$ ken, dan kan hy die ander een dadelik terugkry. Dit gee hom 'n sterk aansporing vind een van die twee ongeënkripteerde komponente uit.

Dit bring ons by die volledige en doeltreffendste aanvalscenario. Oorweeg 'n aanvaller wat radioverkeer tussen 'n teikenfoon en 'n selfoontoring kan onderskep, en wat op een of ander manier gelukkig genoeg is om twee verskillende oproepe op te neem, met die tweede wat onmiddellik na die eerste plaasvind. Stel jou nou voor dat hy op een of ander manier die ongeënkripteerde inhoud van een van die oproepe kon raai. Met so serendipiteit ons aanvaller kan die eerste oproep volledig dekripteer deur 'n eenvoudige XOR tussen die twee stelle pakkies te gebruik.

Natuurlik het geluk niks daarmee te doen nie. Aangesien fone ontwerp is om oproepe te ontvang, sal 'n aanvaller wat die eerste oproep kan afluister, 'n tweede oproep kan begin presies op die oomblik wat die eerste een eindig. Hierdie tweede oproep, as dieselfde enkripsiesleutel weer gebruik word met die teller teruggestel na nul, sal toelaat dat die ongeënkripteerde data herwin word. Verder, aangesien ons aanvaller eintlik die data tydens die tweede oproep beheer, kan hy die inhoud van die eerste oproep herwin - danksy baie spesifiek geïmplementeer klein dingetjies, speel aan sy kant.

Hier is 'n beeld van die algemene aanvalsplan wat uit geneem is oorspronklike dokument:

Aanval van die week: stemoproepe in LTE (ReVoLTE)
Aanval oorsig van ReVoLTE-dokument. Hierdie skema veronderstel dat twee verskillende oproepe gemaak word met dieselfde sleutel. Die aanvaller beheer die passiewe snuffel (links bo), sowel as 'n tweede foon, waarmee hy 'n tweede oproep na die slagoffer se foon kan maak.

So werk die aanval regtig?

Aan die een kant is dit regtig die hoofvraag vir die artikel oor ReVoLTE. Al die bogenoemde idees is in teorie wonderlik, maar hulle laat baie vrae. Soos:

  1. Is dit moontlik (vir akademiese navorsers) om werklik 'n VoLTE-verbinding te onderskep?
  2. Hersleutel regte LTE-stelsels werklik?
  3. Kan jy werklik 'n tweede oproep vinnig en betroubaar genoeg begin sodat die foon en toring die sleutel kan hergebruik?
  4. Selfs as stelsels hersleutel, kan jy werklik weet wat die ongeënkripteerde inhoud van die tweede oproep is - aangesien dinge soos codecs en transkodering die (bietjie-vir-bietjie) inhoud van daardie tweede oproep heeltemal kan verander, selfs al het jy toegang tot die "bits" "kom van jou aanvalfoon af?

ReVoLTE se werk beantwoord sommige van hierdie vrae bevestigend. Die skrywers gebruik 'n kommersiële sagteware-herkonfigureerbare radiostroomsnuffel genaamd Luchtskoop om 'n VoLTE-oproep vanaf die afskakelkant te onderskep. (Ek dink net om die sagteware onder die knie te kry en 'n rowwe idee te kry van hoe dit werk, het maande van die arm gegradueerde studente se lewens geneem - wat tipies is vir hierdie soort akademiese navorsing).

Die navorsers het gevind dat die tweede oproep vinnig genoeg moes gebeur nadat die eerste een geëindig het, om sleutelhergebruik te laat werk, maar nie te vinnig nie—ongeveer tien sekondes vir die operateurs waarmee hulle geëksperimenteer het. Gelukkig maak dit nie saak of die gebruiker die oproep binne hierdie tyd beantwoord nie – die “ring” dws. Die SIP-verbinding self dwing die operateur om dieselfde sleutel te hergebruik.

Dus, baie van die ergste probleme draai om probleem (4) - die ontvang van stukkies van die ongeënkripteerde inhoud van 'n oproep wat deur 'n aanvaller geïnisieer is. Dit is omdat baie met jou inhoud kan gebeur terwyl dit van die aanvaller se foon na die slagoffer se foon oor die sellulêre netwerk beweeg. Byvoorbeeld, sulke vuil truuks soos om 'n geënkodeerde oudiostroom te herkodeer, wat die klank dieselfde laat, maar sy binêre voorstelling heeltemal verander. LTE-netwerke gebruik ook RTP-kopkompressie, wat baie van die RTP-pakket aansienlik kan verander.

Laastens moet die pakkies wat deur die aanvaller gestuur word, min of meer in lyn wees met die pakkies wat tydens die eerste telefoonoproep gestuur is. Dit kan problematies wees, want die verandering van die stilte tydens 'n telefoonoproep lei tot korter boodskappe (ook bekend as gemaksgeraas) wat dalk nie goed by die oorspronklike oproep pas nie.

Afdeling "regte wêreld aanval" Dit is die moeite werd om in detail te lees. Dit spreek baie van die bogenoemde kwessies aan - die skrywers het veral gevind dat sommige kodeks nie her-enkodeer is nie, en dat ongeveer 89% van die teikenoproep se binêre verteenwoordiging herwin kan word. Dit geld vir ten minste twee Europese operateurs wat getoets is.

Dit is 'n verbasend hoë suksessyfer, en eerlikwaar baie hoër as wat ek verwag het toe ek aan hierdie dokument begin werk het.

So wat kan ons doen om dit reg te stel?

Die onmiddellike antwoord op hierdie vraag is baie eenvoudig: aangesien die essensie van die kwesbaarheid 'n sleutelhergebruik (herinstallasie) aanval is, los eenvoudig die probleem op. Maak seker dat 'n nuwe sleutel vir elke telefoonoproep verkry word, en moet nooit toelaat dat die pakkieteller die teller terugstel na nul met dieselfde sleutel nie. Probleem opgelos!

Of dalk nie. Dit sal die opgradering van baie toerusting verg, en eerlikwaar, so 'n oplossing op sigself is nie baie betroubaar nie. Dit sal lekker wees as standaarde 'n veiliger manier kan vind om hul enkripsiemodusse te implementeer wat nie by verstek katastrofies kwesbaar is vir sulke sleutelhergebruikprobleme nie.

Een moontlike opsie is om te gebruik enkripsiemodusse waarin misbruik van nonce nie tot katastrofiese gevolge lei nie. Dit kan te duur wees vir sommige huidige hardeware, maar dit is beslis 'n gebied waaraan ontwerpers in die toekoms moet dink, veral aangesien 5G-standaarde op die punt staan ​​om die wêreld oor te neem.

Hierdie nuwe studie laat ook die algemene vraag ontstaan ​​oor hoekom dieselfde verdomde aanvalle duik telkens in die een standerd na die ander op, waarvan baie baie soortgelyke ontwerpe en protokolle gebruik. Wanneer jy met die probleem gekonfronteer word om dieselfde sleutel oor verskeie wydgebruikte protokolle soos WPA2 te herinstalleer, dink jy nie dit is dalk tyd om jou spesifikasies en toetsprosedures meer robuust te maak nie? Hou op om standaardimplementeerders as bedagsame vennote te behandel wat aandag gee aan jou waarskuwings. Behandel hulle soos (onopsetlike) teëstanders wat onvermydelik dinge verkeerd gaan maak.

Of, alternatiewelik, ons kan doen wat maatskappye soos Facebook en Apple toenemend doen: stemoproepenkripsie laat gebeur op 'n hoër vlak van die OSI-netwerkstapel, sonder om op sellulêre toerustingvervaardigers staat te maak. Ons kan selfs aandring op end-tot-end-enkripsie van stemoproepe, soos WhatsApp met Signal en FaceTime doen, in die veronderstelling dat die Amerikaanse regering net ophou reis ons op. Dan (met die uitsondering van sommige metadata) sou baie van hierdie probleme eenvoudig verdwyn. Hierdie oplossing is veral relevant in 'n wêreld waar selfs regerings is nie seker of hulle hul toerustingverskaffers vertrou nie.

Of ons kan eenvoudig doen wat ons kinders reeds gedoen het: ophou om daardie irriterende stemoproepe te beantwoord.

Bron: will.com

Voeg 'n opmerking