Від перекладача та TL;DR
-
TL; DR:
Здається, VoLTE виявився захищеним ще гірше ніж перші Wi-Fi клієнти з WEP. Винятково архітектурний прорахунок, що дозволяє трохи поXOR'ити трафік і відновити ключ. Атака можлива якщо перебувати поруч із тим, хто телефонує, і той часто робить дзвінки.
-
Дякуємо за наведення та TL;DR
-
Дослідники зробили додаток для визначення, чи вразливий ваш оператор, докладніше . Поділіться в коментарях результатами, в моєму регіоні на Мегафоні VoLTE вимкнено.
Про автора
Метью Грін (Matthew Green).
Я криптограф і професор університету Джона Хопкінса. Я розробляв та аналізував криптографічні системи, що використовуються у бездротових мережах, платіжних системах та платформах захисту цифрового контенту. У своїх дослідженнях я розглядаю різні способи використання криптографії підвищення рівня конфіденційності користувачів.
Давненько я не писав пост формату , І це мене засмучувало. Не тому, що не було атак, а в основному тому, що не було атаки на щось, що досить широко використовується, щоб вивести мене з творчої кризи.
Але сьогодні я натрапив на під назвою ReVoLTE на протоколи, злом яких мене особливо радує, а саме протоколи стільникових мереж (voice over) LTE. Я в захваті від саме цих протоколів – і цієї нової атаки – тому що дуже рідко можна спостерігати зламування реальних протоколів та реалізацій стільникових мереж. В основному тому, що ці стандарти розроблені в прокурених кімнатах та оформлені у 12000-сторінкових документах, які подужає не кожен дослідник. Понад те, реалізація цих атак змушує дослідників використовувати непрості радіо-протоколи.
Таким чином, серйозні криптографічні вразливості можуть поширитися по всьому світу, і можливо будуть використані лише урядами, перш ніж якийсь дослідник зверне на них увагу. Але іноді бувають винятки, і сьогоднішня атака – одна з них.
Автори : Девід Руппрехт (David Rupprecht), Катаріна Коулс (Katharina Kohls), Торстен Хольц (Thorsten Holz) та Крістіна Пеппер (Christina Pöpper) з Рурського університету в Бохумі та Нью-Йоркського університету Абу-Дабі. Це чудова атака на реінсталяцію ключа в голосовому протоколі, який ви, ймовірно, вже використовуєте (якщо припустити, що ви з старшого покоління, яке все ще здійснює телефонні дзвінки за допомогою мобільного телефону).
Спочатку – короткий історичний екскурс.
Що таке LTE та VoLTE?
Основу наших сучасних стандартів стільникової телефонії було закладено в Європі ще в 80-х роках стандартом (Глобальна система мобільного зв'язку). GSM був першим основним стандартом цифрової стільникової телефонії, який ввів ряд революційних функцій, наприклад, використання для захисту телефонних дзвінків Ранній GSM був розроблений насамперед для голосового зв'язку, хоча за гроші можна було .
У міру того, як у стільниковому зв'язку збільшувалася важливість передачі даних, було розроблено стандарти Long Term Evolution (LTE) для раціоналізації цього зв'язку. LTE ґрунтується на групі старіших стандартів, таких як GSM, и та призначений для підвищення швидкості обміну даними. У цій галузі є багато брендованості та , але TL;DR полягає в тому, що LTE – це система передачі даних, яка служить мостом між старими протоколами пакетної передачі даних та майбутніми технологіями стільникової передачі даних .
Зрозуміло, історія говорить нам про те, що як тільки буде достатньо (IP) смуги пропускання, такі поняття, як голос і дані почнуть розмиватись. Те саме стосується і сучасних стільникових протоколів. Щоб зробити цей перехід плавнішим, стандарти LTE визначають (VoLTE), який є IP-стандартом для передачі голосових викликів безпосередньо через площину передачі даних системи LTE, повністю минаючи комутовану частину мережі. Як і у випадку стандартних , VoLTE-дзвінки можуть бути терміновані оператором стільникового зв'язку та підключені до звичайної телефонної мережі. Або (що стає все більш поширеним явищем) вони безпосередньо від одного стільникового клієнта до іншого, і навіть між різними провайдерами.
Як і стандартна VoIP, VoLTE заснована на двох популярних протоколах на базі IP: протокол ініціювання сеансу ( – SIP) для встановлення дзвінка, та транспортний протокол у реальному часі (, який має називатися RTTP, але насправді називається RTP) для обробки голосових даних. VoLTE також додає деякі додаткові оптимізації пропускної здатності, такі як стиснення заголовків.
Добре, яке це стосується шифрування?
LTE, як і має стандартний набір криптографічних протоколів для шифрування пакетів під час їх передачі по повітрю. Вони в основному призначені для захисту ваших даних під час їх переміщення між телефоном (званим «обладнанням користувача», або UE) та вежею стільникового зв'язку (або скрізь, де ваш провайдер вирішує термінувати з'єднання). Це тому, що провайдери стільникового зв'язку розглядають зовнішні пристрої підслуховування як ворогів. Ну, зрозуміло.
(Однак той факт, що з'єднання VoLTE можуть відбуватися безпосередньо між клієнтами у різних мережах провайдерів, означає, що сам протокол VoLTE має деякі додаткові та необов'язкові протоколи шифрування, які можуть відбуватися на більш високих мережевих рівнях. Це не стосується поточної статті, за винятком того факту, що вони можуть зіпсувати все, ми коротко поговоримо про них далі).
Історично шифрування у GSM мало : погані , протоколи, в яких тільки телефон автентифікувався на вежі (це означає, що зловмисник міг видати себе за вежу, породжуючи ) і так далі. LTE виправив багато з очевидних помилок, зберігши при цьому більшу частину колишньої структури.
Почнемо з самого шифрування. Якщо припустити, що створення ключа вже сталося - і ми поговоримо про це через хвилину - то кожен пакет даних шифрується за допомогою потокового режиму шифрування за допомогою якогось шифру під назвою "EEA" (який на практиці може бути реалізований за допомогою таких штук, як AES ). По суті тут механізмом шифрування є , як показано нижче:
Основний алгоритм шифрування пакетів VoLTE (джерело: ). EEA – шифр, COUNT – 32-бітовий лічильник, BEARER – унікальний ідентифікатор сесії, що розділяє з'єднання VoLTE та звичайний інтернет-трафік. "DIRECTION" вказує, в якому напрямку йде трафік - від UE до вишки або навпаки.
Так як сам алгоритм шифрування (EEA) може бути реалізований з використанням сильного шифру типу AES, то малоймовірно, що буде якась пряма атака на сам шифр, як це . Однак, очевидно, що навіть при сильному шифрі ця схема шифрування є чудовим засобом вистрілити собі в ногу.
Зокрема: у стандарті LTE використовується (неавтентифікований) потоковий шифр з режимом, який буде вразливим, якщо лічильник - та інші входи, такі як "bearer" і "direction" - будь-коли будуть використовуватися повторно. У сучасному мові термін цього поняття – «атака з повторним використанням nonce», але потенційні ризики тут є чимось сучасним. Вони відомі і стародавні, що сягають часів глем-металу і навіть диско.
Атаки на перевикористання nonce у CTR-режимі існували ще тоді, коли Poison стали відомі
Заради справедливості, в стандартах LTE сказано: "Не використовуйте ці лічильники повторно, ну будь ласка". Але стандарти LTE займають близько 7000 сторінок, і в будь-якому випадку, це все одно, що благати малюків не грати з пістолетом. Вони неминуче це зроблять і відбудуться жахливі речі. У даному випадку пістолетом, що розряджається, є атака з повторним використанням потоку ключа, в якій два різних конфіденційних повідомлення XOR-ят з одними і тими ж байтами потоку ключа. Відомо, що це .
Що таке ReVoLTE?
Атака ReVoLTE демонструє, що на практиці ця вразлива конструкція шифрування неправильно використовується реальним обладнанням. Зокрема автори аналізують реальні дзвінки VoLTE, зроблені з використанням комерційного обладнання, і показують, що вони можуть використовувати щось, зване «атакою на перевстановлення ключа». (Велика заслуга у знаходженні цієї проблеми належить (Raza & Lu), які першими вказали на потенційну вразливість. Але дослідження ReVoLTE перетворюють її на практичну атаку).
Давайте я покажу вам коротко суть атаки, хоча вам варто подивитися і .
Можна припустити, що як тільки LTE встановлює з'єднання пакетної передачі даних, завдання передачі голосу LTE стає лише питанням маршрутизації голосових пакетів по цьому з'єднанню разом з рештою вашого трафіком. Іншими словами, VoLTE буде концепцією, яка існує лише над [моделі OSI – прим пров.]. Це не зовсім так.
Фактично канальний рівень LTE вводить поняття «bearer». Bearer – це окремі ідентифікатори сеансів, які поділяють різні типи пакетного трафіку. Звичайний інтернет-трафік (ваш Twitter та Snapchat) проходить через один bearer. Сигналізація SIP для VoIP йде через інший, а пакети голосового трафіку обробляються третьому. Я не дуже добре розуміюся на механізмах радіоканалів та мережевої маршрутизації LTE, але вважаю, що це зроблено саме так, тому що мережі LTE хочуть забезпечити роботу механізмів QoS (якості обслуговування), щоб різні потоки пакетів оброблялися з різними рівнями пріоритету: тобто. ваші другосортні TCP з'єднання з Facebook може мати нижчий пріоритет, ніж ваші голосові дзвінки в реальному часі.
Це загалом не проблема, але наслідки цього такі. Ключі для шифрування LTE створюються окремо кожного разу при встановленні нового "bearer". В принципі, це має відбуватися знову щоразу, коли ви робите новий телефонний дзвінок. Це призведе до того, що для кожного дзвінка буде використовуватися різний ключ шифрування, що унеможливлює повторне використання одного і того ж ключа для шифрування двох різних наборів пакетів голосових дзвінків. Дійсно, стандарт LTE говорить щось на зразок «ви повинні використовувати різні ключі щоразу, коли ви встановлюєте новий bearer для обробки нового телефонного дзвінка». Але це не означає, що так відбувається насправді.
Насправді, в реальних реалізаціях два різні виклики, що відбуваються в безпосередній тимчасовій близькості, використовуватимуть один і той самий ключ — незважаючи на те, що між ними налаштовуються нові (одноіменні) bearer. Єдина практична зміна, яка відбувається між цими викликами, полягає в тому, що лічильник шифрування скидається на нуль. У літературі таке іноді називають . Можна стверджувати, що по суті це помилка реалізації, хоча в цьому випадку ризики, як здається, значною мірою випливають із самого стандарту.
На практиці ця атака призводить до повторного використання потоку ключа, де зловмисник може отримати зашифровані пакети $inline$C_1 = M_1 oplus KS$inline$ і $inline$C_2 = M_2 oplus KS$inline$, що дозволяє обчислити $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Ще краще, якщо зловмисник знає одну з $inline$M_1$inline$ або $inline$M_2$inline$, він може відразу ж відновити іншу. Це дає йому сильний стимул дізнатися один із двох незашифрованих компонентів.
Це призводить до повного і найефективнішого сценарію атаки. Розглянемо атакуючого, який може перехоплювати радіотрафік між цільовим телефоном та стільниковою вежею, і якому якимось хитрим чином «пощастило» записати два різні дзвінки, де другий відбувається відразу після першого. Тепер уявіть собі, що він може вгадати нешифрований зміст одного з дзвінків. При такій щасливого випадку Наш зловмисник може повністю розшифрувати перший виклик, використовуючи простий XOR між двома наборами пакетів.
Зрозуміло, удача тут ні до чого. Оскільки телефони призначені для прийому дзвінків, зловмисник, який може підслухати перший дзвінок, зможе ініціювати другий дзвінок саме в той момент, коли закінчиться перший дзвінок. Цей другий дзвінок у разі повторного використання того ж ключа шифрування зі лічильником, скинутим на нуль, дозволить відновити нешифровані дані. Більше того, оскільки наш зловмисник фактично контролює дані під час другого дзвінка, він може відновити вміст першого дзвінка – завдяки безлічі специфічно реалізованих дрібниць, що грають на його боці.
Ось зображення загального плану атаки, взяте з :
Огляд атаки з . Ця схема передбачає, що відбуваються два різних виклики з використанням одного й того самого ключа. Атакуючий контролює пасивний сніфер (вгорі зліва), а також другий телефон, за допомогою якого він може здійснити другий дзвінок на жертву.
Так атака справді працює?
З одного боку, це справді головне питання для статті про ReVoLTE. Теоретично всі вищеперелічені ідеї чудові, але залишають безліч питань. Такі як:
- Чи можливо (академічним дослідникам) реально перехопити VoLTE-з'єднання?
- Чи реальні LTE-системи встановлюють ключі?
- Чи можете ви насправді ініціювати другий дзвінок досить швидко і надійно, щоб телефон і вежа повторно використовували ключ?
- Навіть якщо системи встановлюють ключі, чи можете ви насправді дізнатися нешифрований вміст другого дзвінка – враховуючи, що такі речі, як кодеки і перекодування можуть повністю змінити (побітовий) вміст цього другого дзвінка, навіть якщо у вас є доступ до «бітів», вихідним з вашого атакуючого телефону?
На деякі з цих питань робота ReVoLTE відповідає ствердно. Автори використовують комерційний програмно-реконфігурований сніффер радіопотоку під назвою для перехоплення дзвінка VoLTE із боку низхідної лінії. (Я думаю, що просте оволодіння ПЗ і зразкове розуміння того, як воно працює, забрало місяці життя у бідолах-аспірантів – що типово для подібних академічних досліджень).
Дослідники виявили, що для спрацювання повторного використання ключа другий дзвінок має відбутися досить швидко після завершення першого, але не надто приблизно через десять секунд для операторів, з якими вони експериментували. На щастя, немає значення, чи відповість користувач на дзвінок протягом цього часу – «дзвінок», тобто. сам SIP-зв'язок змушує оператора повторно використовувати той самий ключ.
Таким чином, багато з найбільш паршивих проблем обертаються навколо проблеми (4) – отримання бітів незашифрованого вмісту виклику, ініційованого атакуючим. Це відбувається тому, що з вашим вмістом може багато чого статися в міру того, як він переходить від телефону зловмисника до телефону жертви через мережу. Наприклад, такі капості, як перекодування закодованого звукового потоку, що залишає звук колишнім, але повністю змінює його двійкове уявлення. У мережах LTE також використовується стиснення заголовків RTP, яке може істотно змінити більшу частину пакета RTP.
Нарешті, пакети, надіслані зловмисником, повинні шикуватися приблизно в одну лінію з пакетами, які вирушили під час першого телефонного дзвінка. Це може бути проблематично, оскільки модифікація тиші під час телефонного дзвінка призводить до більш коротких повідомлень (т.зв. комфортний шум), які можуть погано поєднуватися з вихідним дзвінком.
варто прочитати у всіх подробицях. У ньому розглядаються багато з перелічених вище проблем – зокрема, автори виявили, що деякі кодеки не перекодовані, і що приблизно 89% двійкового подання цільового виклику може бути відновлено. Це актуально, як мінімум, для двох європейських операторів, які були протестовані.
Це напрочуд високий рівень успіху, і, відверто кажучи, набагато вищий, ніж я очікував, коли починав роботу над цим документом.
То що ми можемо зробити для виправлення?
Невідкладна відповідь на це питання дуже проста: оскільки суть вразливості в атаці на перевикористання (реінсталяцію) ключа, просто виправте цю проблему. Переконайтеся, що для кожного телефонного дзвінка отримано новий ключ, і ніколи не дозволяйте лічильнику пакетів скидати лічильник назад на нуль за допомогою того самого ключа. Проблема вирішена!
А може й ні. Для цього потрібно модернізувати велику кількість обладнання, і, відверто кажучи, сам по собі такий фікс не супернадійний. Було б непогано, якби стандарти змогли знайти безпечніший спосіб реалізації своїх режимів шифрування, який не є за умовчанням катастрофічно вразливим для таких проблем перевикористання ключів.
Одним із можливих варіантів є використання . Це може бути занадто дорогим для деяких сучасних апаратних засобів, але це, безумовно, напрям, про який проектувальники повинні думати в майбутньому, особливо враховуючи те, що стандарти 5G ось-ось захоплять світ.
Це нове дослідження також порушує спільне питання того, чому , багато з яких використовують дуже схожі конструкції та протоколи. Коли ви стикаєтеся з проблемою реінсталяції одного і того ж ключа в декількох широко поширених протоколах, таких як WPA2, вам не здається, що, можливо, таки настав час зробити ваші специфікації та процедури тестування надійнішими? Досить уже ставитися до реалізаторів стандартів як до вдумливих партнерів, уважних до ваших попереджень. Поводьтеся з ними як з (ненавмисними) противниками, які неминуче збираються впровадити все неправильно.
Ну або як варіант, ми можемо зробити те, що все частіше роблять компанії типу Facebook і Apple: зробити так, щоб шифрування голосових дзвінків відбувалося на вищому рівні мережевого стека OSI, не покладаючись на виробників обладнання. Ми навіть можемо просувати наскрізне шифрування голосових викликів, як це роблять WhatsApp із Signal та FaceTime, припускаючи, що уряд США просто перестане . Тоді (за винятком деяких метаданих) багато з цих проблем просто зникли б. Це рішення особливо актуальне у світі, де .
Або ми можемо просто робити те, що вже зробили наші діти: взяти і перестати відповідати на ці набридливі голосові дзвінки.
Джерело: habr.com