Van de vertaler en TL;DR
TL;DR:
Het lijkt erop dat VoLTE zelfs slechter beveiligd is dan de eerste Wi-Fi-klanten met WEP. Een puur architectonische fout die het mogelijk maakt om het verkeer een beetje te XOR'en en de sleutel te herstellen. De aanval is mogelijk als je dichtbij de beller bent en deze vaak belt.
Bedankt voor de tip en TL;DR
Onderzoekers hebben een applicatie ontwikkeld om te bepalen of jouw provider kwetsbaar is, meer details . Deel je resultaten in de commentaren, in mijn regio is VoLTE uitgeschakeld bij MegaFon.
Over de auteur
Matthew Green.
Ik ben cryptograaf en professor aan de Johns Hopkins University. Ik heb cryptografische systemen ontwikkeld en geanalyseerd die worden gebruikt in draadloze netwerken, betalingssysteem en digitale contentbeveiligingsplatforms. In mijn onderzoek bekijk ik verschillende manieren om cryptografie te gebruiken om het privacy-niveau van gebruikers te verhogen.
Het is een tijdje geleden dat ik een post van het formaat , en dat maakt me verdrietig. Niet omdat er geen aanvallen waren, maar voornamelijk omdat er geen aanval was op iets genoeg wijdverspreid om me uit mijn creatieve crisis te halen.
Maar vandaag stuitte ik op een met de naam ReVoLTE op protocollen waarvan ik het leuk vind dat ze worden gehackt, namelijk de mobiele netwerken (voice over) LTE-protocollen. Ik ben enthousiast over deze protocollen ā en deze nieuwe aanval ā omdat het heel zeldzaam is om echte protocollen en implementaties van mobiele netwerken te zien worden gehackt. Dit komt voornamelijk omdat deze standaarden zijn ontwikkeld in met sigarettenrook gevulde kamers en zijn vastgelegd in 12000 pagina's tellende documenten die niet door elke onderzoeker kunnen worden doorgrond.
Bovendien dwingen de implementaties van deze aanvallen onderzoekers om ingewikkelde radioprotocols te gebruiken. Daarom kunnen ernstige cryptografische kwetsbaarheden zich wereldwijd verspreiden en mogelijk alleen door overheden worden gebruikt, voordat een onderzoeker zijn aandacht erop vestigt. Maar af en toe zijn er uitzonderingen, en de aanval van vandaag is er een van.
Auteurs : David Rupprecht, Katharina Kohls, Thorsten Holz en Christina Pƶpper van de Ruhr-Universiteit Bochum en de New York University Abu Dhabi. Dit is een prachtige aanval op de herinstallatie van de sleutel in het stemprotocol dat je waarschijnlijk al gebruikt (tenzij je tot de oudere generatie behoort die nog steeds met een mobiele telefoon belt).
Laten we beginnen met een korte historische terugblik.
Wat zijn LTE en VoLTE?
De basis van onze moderne mobiele telefonie standaarden werd in Europa in de jaren '80 gelegd met de standaard (Globaal Systeem voor Mobiele Communicatie). GSM was de eerste belangrijke standaard voor digitale mobiele telefonie die een aantal revolutionaire functies introduceerde, zoals het gebruik van ter bescherming van telefoongesprekken. Vroeg GSM was in de eerste plaats voor spraakcommunicatie ontworpen, hoewel het tegen betaling mogelijk was om ook andere gegevens .
Naarmate het belang van gegevensoverdracht in mobiele communicatie toenam, werden Long Term Evolution (LTE) standaarden ontwikkeld om dit type communicatie te stroomlijnen. LTE is gebaseerd op een reeks oudere standaarden, zoals GSM, en en is ontworpen om de datasnelheden te verhogen. Op dit gebied zijn er veel branding en , maar TL;DR is dat LTE een gegevensoverdrachtsysteem is dat als een brug fungeert tussen oude protocols voor gegevensoverdracht en toekomstige technologieƫn voor mobiele gegevensoverdracht. .
Natuurlijk vertelt de geschiedenis ons dat zodra er voldoende (IP) bandbreedte beschikbaar is, concepten zoals 'stem' en 'gegevens' beginnen te vervagen. Dit geldt ook voor de moderne mobiele protocollen. Om deze overgang soepeler te maken, definiƫren de LTE-standaarden (VoLTE), wat een IP-standaard is voor het rechtstreeks overbrengen van spraakoproepen via het dataplatform van het LTE-systeem, volledig voorbijgaand aan het geschakelde gedeelte van het mobiele netwerk. Net als bij standaard worden gerouteerd. direct van de ene mobiele klant naar de andere, en zelfs tussen verschillende providers.
Net als standaard VoIP is VoLTE gebaseerd op twee populaire IP-gebaseerde protocollen: het sessie-initiatprotocol ( ā SIP) voor het tot stand brengen van gesprekken, en het real-time transportprotocol (, dat RTP moet heten, maar eigenlijk RTP wordt genoemd) voor het verwerken van spraakgegevens. VoLTE voegt ook enkele extra optimalisaties voor bandbreedte toe, zoals headercompressie.
Wat heeft dit te maken met encryptie?
LTE, net zoals , heeft een standaard set van cryptografische protocollen voor het versleutelen van pakketten tijdens hun overdracht via de lucht. Ze zijn voornamelijk bedoeld om uw gegevens te beschermen tijdens het transport tussen de telefoon (de zogenaamde 'gebruikersapparatuur', of UE) en de mobiele zendmast (of waar uw provider ervoor kiest de verbinding te termineren). Dit komt omdat mobiele providers externe afluisterapparaten beschouwen als tegenstanders. Uiteraard.
(Het feit dat VoLTE-verbindingen rechtstreeks tussen clients in verschillende netwerken van providers kunnen plaatsvinden, betekent dat het VoLTE-protocol enkele extra en optionele encryptieprotocollen kan hebben die op hogere netwerkniveaus kunnen plaatsvinden. Dit valt niet binnen het bereik van dit artikel, behalve dat ze alles kunnen verpesten. We zullen ze later kort bespreken.)
Historisch gezien had encryptie in GSM : slechte , protocollen waarbij alleen de telefoon zich autenticeerde bij de zendmast (dit betekent dat een aanvaller zich als zendmast kon voordoen, wat leidde tot ) en dergelijke. LTE heeft veel van de voor de hand liggende fouten hersteld, maar heeft daarbij het grootste deel van de oude structuur behouden.
Laten we beginnen met de encryptie zelf. Als we aannemen dat de sleutel al is aangemaakt ā en daar gaan we het zo over hebben ā wordt elk datapakket versleuteld met behulp van een stroommodus encryptie met een of andere encryptie genaamd 'EEA' (die in de praktijk kan worden geĆÆmplementeerd met dingen zoals AES). In wezen is hier het encryptiemechanisme , zoals hieronder weergegeven:
De hoofdalgoritme voor het versleutelen van VoLTE-pakketten (bron: ). EEA ā de cipher, 'COUNT' ā een 32-bits teller, 'BEARER' ā een unieke sessie-identificator die VoLTE-verbindingen scheidt van reguliere internetverkeer. 'DIRECTION' geeft aan in welke richting het verkeer gaat ā van UE naar de toren of omgekeerd.
Aangezien het versleutelingsalgoritme (EEA) kan worden geĆÆmplementeerd met een sterke cipher zoals AES, is het onwaarschijnlijk dat er directe aanvallen op de cipher zelf zullen plaatsvinden, zoals dat . Het is echter duidelijk dat zelfs met een sterke cipher dit versleutelingsschema een uitstekende manier biedt om jezelf in de voet te schieten.
In het bijzonder: de LTE-standaard gebruikt een (niet-geauthenticeerde) stroomcipher met een modus die extreem kwetsbaar zal zijn als de teller - en andere ingangen zoals 'bearer' en 'direction' - ooit opnieuw zullen worden gebruikt. In de moderne terminologie heet dit 'een nonce hergebruik aanval', maar de potentiƫle risico's zijn niets nieuws. Ze zijn bekend en oud, teruggaand tot de tijd van glam metal en zelfs disco.
Aanvallen op nonce hergebruik in CTR-modus bestonden al in de tijd dat Poison bekend werd
Om recht te doen aan de feiten, zeggen de LTE-standaarden: 'Hergebruik deze tellers alsjeblieft niet.' Maar de LTE-standaarden beslaan ongeveer 7000 pagina's, en hoe dan ook, het is alsof je kleuters smeekt niet met een pistool te spelen. Ze zullen het onvermijdelijk doen, en er zullen vreselijke dingen gebeuren. In dit geval is het schietende pistool een aanval met hergebruik van de sleutelstream, waarbij twee verschillende vertrouwelijke berichten worden XOR'd met dezelfde bytes van de sleutelstream. Het is bekend dat dit .
Wat is ReVoLTE?
De ReVoLTE-aanval demonstreert dat deze zeer kwetsbare versleuteling in de praktijk verkeerd wordt gebruikt door echte apparatuur. In het bijzonder analyseren de auteurs daadwerkelijke VoLTE-gesprekken die zijn gemaakt met commerciƫle apparatuur, en tonen ze aan dat ze iets kunnen gebruiken dat een 'sleutelherinstallatie-aanval' wordt genoemd. (Een groot deel van de verdienste voor het vinden van dit probleem gaat naar (Raza & Lu), die als erste op de mogelijke kwetsbaarheid wezen. Maar ReVoLTE-onderzoeken maken er een praktische aanval van).
Laat me kort de essentie van de aanval uitleggen, hoewel je ook zou moeten kijken naar .
Je zou kunnen aannemen dat zodra LTE een dataverbindingsverbinding tot stand brengt, de overdracht van spraak over LTE slechts een kwestie van routering van spraakpakketten via deze verbinding samen met al je andere verkeer wordt. Met andere woorden, VoLTE zal een concept zijn dat alleen bestaat boven [OSI-modellen ā zie bijv.]. Dit is niet helemaal juist.
Eigenlijk introduceert de datalinklaag van LTE het concept 'bearer'. Bearer zijn afzonderlijke sessie-identificaties die verschillende soorten pakketverkeer scheiden. Gewoon internetverkeer (je Twitter en Snapchat) gaat via Ć©Ć©n bearer. SIP-signalisatie voor VoIP gaat via een andere, en de spraakverkeerspakketten worden op een derde verwerkt. Ik ben niet erg goed thuis in de mechanismen van radiokanalen en netwerkrouting van LTE, maar ik veronderstel dat dit zo is gedaan omdat LTE-netwerken willen zorgen voor de werking van QoS-mechanismen (kwaliteit van dienstverlening), zodat verschillende pakketstromen met verschillende prioriteitsniveaus worden verwerkt: d.w.z. jouw minder belangrijke TCP-verbindingen met Facebook mogelijk een lagere prioriteit hebben dan jouw realtime spraakoproepen.
Dit is op zich geen probleem, maar de gevolgen zijn als volgt. Sleutels voor de encryptie van LTE worden elke keer afzonderlijk aangemaakt bij het tot stand brengen van een nieuwe 'bearer'. In principe zou dit elke keer moeten gebeuren, wanneer je een nieuw telefoongesprek voert. Dit zal ertoe leiden dat voor elk gesprek een andere encryptiesleutel wordt gebruikt, wat het hergebruik van dezelfde sleutel voor de encryptie van twee verschillende sets spraakoproep-pakketten uitsluit. In feite zegt de LTE-standaard iets als 'je moet verschillende sleutels gebruiken elke keer dat je een nieuwe bearer instelt voor het verwerken van een nieuw telefoongesprek'. Maar dat betekent niet dat dit in de praktijk ook zo gebeurt.
In werkelijkheid zullen twee verschillende aanroepen die zich in directe tijds dichtbij bevinden, dezelfde sleutel gebruiken - ondanks het feit dat er nieuwe (met dezelfde naam) bearers worden ingesteld. De enige praktische wijziging die tussen deze aanroepen plaatsvindt, is dat de encryptieteller op nul wordt gezet. In de literatuur wordt dit soms aangeduid als . Men kan stellen dat dit in wezen een implementatiefout is, hoewel de risico's in dit geval, zoals het lijkt, grotendeels voortkomen uit de standaard zelf.
In de praktijk leidt deze aanval tot hergebruik van de sleutelstream, waarbij een aanvaller de versleutelde pakketten $inline$C_1 = M_1 oplus KS$inline$ en $inline$C_2 = M_2 oplus KS$inline$ kan verkrijgen, waardoor $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$ kan worden berekend. Het wordt nog beter, als de aanvaller een van de $inline$M_1$inline$ of $inline$M_2$inline$ kent, kan hij onmiddellijk de andere herstellen. Dit geeft hem een sterke stimulans om een van de twee niet-versleutelde componenten te achterhalen.
Dit brengt ons bij het meest volledige en effectieve aanvalsscenario. Stel je een aanvaller voor die het radiod verkeer tussen de doeltelefoon en de cellulaire toren kan onderscheppen, en die op de een of andere slimme manier 'geluk' heeft gehad met het opnemen van twee verschillende gesprekken, waarbij het tweede gesprek onmiddellijk na het eerste plaatsvindt. Stel je nu voor dat hij op de een of andere manier de niet-versleutelde inhoud van een van de gesprekken kan raden. Bij deze gelukkige toevalligheid kan onze aanvaller het eerste gesprek volledig ontcijferen door een eenvoudige XOR tussen twee sets pakketten te gebruiken.
Natuurlijk heeft geluk hier niets mee te maken. Aangezien telefoons zijn ontworpen om gesprekken te ontvangen, kan een aanvaller die het eerste gesprek kan afluisteren, het tweede gesprek initiĆ«ren precies op het moment dat het eerste eindigt. Dit tweede gesprek, in het geval van hergebruik van dezelfde encryptiesleutel met de teller teruggezet naar nul, zal in staat zijn om de niet-versleutelde gegevens te herstellen. Bovendien, aangezien onze aanvaller feitelijk de gegevens controleert tijdens het tweede gesprek, kan hij de inhoud van het eerste gesprek herstellen - dankzij een aantal specifiek geĆÆmplementeerde detail, die in zijn voordeel spelen.
Hier is een afbeelding van het algemene aanvalsplan, genomen uit :
Overzicht van de aanval vanuit . Dit schema veronderstelt dat er twee verschillende oproepen plaatsvinden met hetzelfde sleutel. De aanvaller controleert een passieve sniffer (bovenaan links) en ook de tweede telefoon waarmee hij een tweede oproep naar het slachtoffer kan doen.
Werkt de aanval echt?
Aan de ene kant is dit inderdaad de belangrijkste vraag voor een artikel over ReVoLTE. Theoretisch zijn al deze ideeƫn geweldig, maar wekken ze veel vragen op. Zoals:
- Is het mogelijk (voor academische onderzoekers) om daadwerkelijk een VoLTE-verbinding af te luisteren?
- Installeren echte LTE-systemen de sleutels opnieuw?
- Kun je daadwerkelijk een tweede oproep snel en betrouwbaar initiƫren, zodat de telefoon en de toren de sleutel opnieuw gebruiken?
- Zelfs als systemen de sleutels opnieuw installeren, kun je dan daadwerkelijk de ongecodeerde inhoud van de tweede oproep achterhalen ā rekening houdend met het feit dat zaken zoals codecs en hercodering de (per bit) inhoud van die tweede oproep volledig kunnen veranderen, zelfs als je toegang hebt tot de 'bits' die van je aanvallerstelefoon komen?
Op sommige van deze vragen geeft het werk van ReVoLTE bevestigende antwoorden. De auteurs gebruiken een commercieel softwarematig programmeerbare radiosniffer genaamd om de VoLTE-oproep aan de zijde van de downlink af te luisteren. (Ik denk dat het simpelweg beheersen van de software en een ruw idee van hoe het werkt maanden van het leven van de arme promovendi heeft gekost ā wat typisch is voor dit soort academische onderzoeken).
De onderzoekers ontdekten dat voor de hergebruik van de sleutel de tweede oproep snel genoeg moet plaatsvinden nadat de eerste is beĆ«indigd, maar niet te snel ā ongeveer tien seconden voor de operators waarmee ze experimenteerden. Gelukkig maakt het niet uit of de gebruiker binnen deze tijd opneemt ā de 'oproep', d.w.z. de SIP-verbinding zelf, dwingt de operator om dezelfde sleutel opnieuw te gebruiken.
Veel van de slechtste problemen draaien om probleem (4) ā het verkrijgen van de niet-versleutelde bits van de inhoud van een oproep die door de aanvaller is geĆÆnitieerd. Dit gebeurt omdat er met jouw inhoud veel kan gebeuren terwijl deze van de telefoon van de aanvaller naar de telefoon van het slachtoffer gaat via het mobiele netwerk. Bijvoorbeeld, kwaadaardige actie zoals het herschalen van de gecodeerde audiostream, waardoor het geluid hetzelfde blijft, maar de binaire representatie volledig verandert. In LTE-netwerken wordt ook gebruikgemaakt van het comprimeren van RTP-koppen, wat een aanzienlijk deel van het RTP-pakket kan veranderen.
Ten slotte moeten de pakketten die door de aanvaller zijn verzonden, ongeveer in Ć©Ć©n lijn liggen met de pakketten die tijdens het eerste telefoongesprek zijn verzonden. Dit kan problematisch zijn, omdat het modificeren van stiltes tijdens het telefoongesprek leidt tot kortere berichten (het zogenaamde comfortgeluid), wat slecht kan samenvallen met het originele gesprek.
moet in detail worden gelezen. Hierin worden vele van de bovenstaande problemen besproken ā met name ontdekten de auteurs dat sommige codecs niet worden herschaald en dat ongeveer 89% van de binaire representatie van de doeloproep kan worden hersteld. Dit is relevant voor ten minste twee Europese operators die zijn getest.
Dit is een verrassend hoog slagingspercentage, en eerlijk gezegd veel hoger dan ik had verwacht toen ik begon met het schrijven van dit document.
Wat kunnen we doen om dit op te lossen?
Het urgente antwoord op deze vraag is van cruciaal belang: aangezien de aard van de kwetsbaarheid zich richt op de aanval op het hergebruiken (herinstalleren) van de sleutel, los deze kwestie gewoon op. Zorg ervoor dat voor elk telefoongesprek een nieuwe sleutel wordt verkregen, en laat nooit de pakket teller terugzetten naar nul met dezelfde sleutel. Probleem opgelost!
Misschien ook niet. Dit zou een upgrade van veel apparatuur vereisen en, eerlijk gezegd, is zo'n fix op zichzelf niet bijzonder betrouwbaar. Het zou goed zijn als standaarden een veiligere manier zouden kunnen vinden om hun encryptiemethoden te implementeren die niet standaard catastrofaal kwetsbaar is voor soortgelijke problemen van hergebruik van sleutels.
Een van de mogelijke opties is het gebruik van . Dit kan te duur zijn voor sommige hedendaagse hardware, maar het is zeker een richting waar ontwerpers in de toekomst over moeten nadenken, vooral gezien het feit dat de 5G-standaarden de wereld binnenkort zullen veroveren.
Dit nieuwe onderzoek roept ook de algemene vraag op waarom , waarvan vele gebruikmaken van zeer vergelijkbare constructies en protocollen. Wanneer je geconfronteerd wordt met het probleem van het herinstalleren van dezelfde sleutel in verschillende veelvoorkomende protocollen, zoals WPA2, lijkt het dan niet misschien tijd om je specificaties en testprocedures betrouwbaarder te maken? Stop met het beschouwen van standaardimplementators als bedachtzame partners die aandacht hebben voor je waarschuwingen. Behandel ze als (onbedoelde) tegenstanders die onvermijdelijk alles verkeerd zullen implementeren.
Of als alternatief kunnen we doen wat bedrijven zoals Facebook en Apple steeds vaker doen: ervoor zorgen dat de encryptie van spraakoproepen op een hoger niveau van de OSI-netwerkstack plaatsvindt, zonder afhankelijk te zijn van apparatuur producenten van mobiele netwerken. We kunnen zelfs end-to-end encryptie van spraakoproepen promoten, zoals WhatsApp doet met Signal en FaceTime, ervan uitgaand dat de Amerikaanse overheid gewoon stopt met . Dan zouden veel van deze problemen simpelweg verdwijnen (behalve sommige metadata). Deze oplossing is bijzonder relevant in een wereld waarin .
Of kunnen we gewoon doen wat onze kinderen al hebben gedaan: simpelweg stoppen met het beantwoorden van die vervelende telefoongesprekken.
Bron: habr.com
