Чому Matrix виявляє критичні вади у військових операціях: технічний аналіз криптографічної нестабільності та архітектурних недоліків
Впровадження Matrix та Element у військових та державних мережах розцінювалося як значна перемога шифрування наскрізь та цифрової суверенності. Та ретельніший аналіз того, як ці системи функціонують в умовах активного конфлікту, розкриває фундаментальну невідповідність між принципами цивільного проектування та операційною реальністю сучасної війни. Це не критика Matrix як цивільної платформи комунікацій. Це радше аналіз того, що відбувається, коли систему, спроектовану для приватності цивільних користувачів, зустрічають загрози, для яких вона ніколи не була розроблена.
Останній криптографічний аналіз, особливо робота, описана в дослідженні Soatok щодо вразливостей у vodozemac, розкрив розломи, які повинні турбувати будь-кого, хто розгортає Matrix у високоризикових операціях безпеки. Проблеми виходять далеко за межі криптографії в оперативну безпеку, моделі адміністративних привілеїв та роль людської помилки в системах, спроектованих з надто великою кількістю рухомих частин.
Криптографічна нестабільність: проблема Vodozemac
Перехід з libolm на vodozemac, Rust-бібліотеку криптографії для Matrix, був представлений як поліпшення безпеки. Насправді він запровадив нову категорію ризику. Бібліотека пройшла значні переписи та зараз зберігає зростаючий набір задокументованих проблем, які дозволяють зловмисникам здійснювати атаки на витяг ключів та порушення цілісності сесій способами, які раніше були неможливі.
Основна проблема не в тому, що vodozemac погано написаний. Скоріше, це в тому, що підхід Matrix до криптографічних оновлень створює те, що можна назвати проблемою “постійного потоку”. Зі сотнями розробників у дозинах організацій та юрисдикцій, які постійно змінюють кодову базу, немає стабільної криптографічної основи. Військова одиниця не може просто розгорнути Matrix, перевірити його властивості безпеки та зберігати цю перевірку невизначено довго. Замість цього, кожен патч, кожне оновлення від спільноти открытого коду приносить можливість нових векторів атаки.
Це стає більше ніж технічною проблемою, коли ви розумієте операційний контекст. Військова одиниця не може швидко перейти на іншу криптографічну бібліотеку, якщо виникне проблема. Вони не можуть розділити проект та підтримувати свою власну безпечну версію без ресурсів спеціалізованої команди криптографії. Вони змушені приймати те, що виробляє спільнота открытого коду, включно з внесками від учасників у ворожих державах або тих, на кого впливають державні спонсори.
Розглянемо такий сценарій: одиничний commit від розробника, який стверджує про виправлення проблеми продуктивності, було об’єднано в vodozemac. Зміна запровадила тонкий зміщення у генерації випадкових чисел. Це зміщення залишається невиявленим при тестуванні, оскільки воно проявляється лише при певних операційних умовах, з якими цивільні тестери ніколи не зустрічаються. Тим часом розвідувальна агенція з передовими можливостями криптоаналізу виявляє недолік та тихо його використовує. До часу, коли армія виявить проблему, багаторічна комунікація буде скомпрометована.
Втома від верифікації як поверхня атаки
У Matrix процес cross-signing та emoji-верифікації представлений як основоположний для безпеки. У військовій практиці це стає обтяженням. Коли новий пристрій приєднується до захищеного каналу з 500 учасниками, система пропонує верифікацію. Це означає порівняння послідовності емодзі на пристроях для підтвердження легітимності з’єднання.
Теоретично це хороша практика безпеки. У реальності польових операцій це гуманітарна катастрофа, яка чекає. Офіцер, який керує тактичною операцією під вогнем артилерії, не буде ретельно перевіряти всі десять збігів емодзі для нового учасника. Вони або пропустять верифікацію взагалі, або проведуть поверхневу перевірку, яка задовольнить спостерігача, але не представляє жодної фактичної валідації безпеки.
Це створює те, що криптографи називають “втомою від верифікації”. Система пропонує багато варіантів безпеки, більшість з яких оператор покидає під стресом. Противник, який розуміє цю поведінку, може систематично її використовувати. Розташувавши атаку Man-in-the-Middle на мережевому вузькому місці, противник може подати підроблені запити верифікації, які виглядають достатньо легітимно, щоб стресований оператор їх прийняв.
Атака розгортається тихо. Скомпрометований пристрій тепер передає всі майбутні повідомлення зловмиснику. Але немає попереджень, немає підозрілих логів, немає ознак того, що щось пішло не так. Офіцер продовжує вірити, що безпечно комунікує зі своїм підрозділом, тоді як кожне слово перехоплюється.
Фундаментальна проблема в тому, що Matrix прийняла рішення щодо безпеки, які припускають цивільні випадки використання, де оператори мають час на обережне прийняття рішень. Військові операції не надають цієї розкоші.
Витік метаданих: золота жила розвідки
Більшість обговорень щодо зашифрованої комунікації зосереджуються на вмісті повідомлень. У військових операціях метадані часто більш цінні, ніж самі повідомлення. Архітектура Matrix робить метадані надзвичайно видимими для кожного, хто має адміністративний доступ до сервера.
Адміністратор Matrix-сервера може спостерігати в реальному часі, хто з ким комунікує, як часто відбуваються ці комунікації, в якій час доби комунікація найвищої інтенсивності та які типи пристроїв використовуються. Все це видимо навіть якщо кожне повідомлення зашифровано з ідеальною forward secrecy.
Тепер розглянемо, що розвідувальна операція може зробити з цією інформацією. Якщо противник управляє скомпрометувати адміністратора Matrix-сервера через вербування чи експлуатацію, вони отримують доступ до комплексної карти вашої командної структури без необхідності розшифровувати одне повідомлення.
Розвідувальна цінність метаданих була встановлена задовго до того, як зашифрована комунікація стала широкорозповсюдженою. Програми збору метаданих АНБ орієнтувалися на метадані комунікацій, оскільки вони розкривають операційні закономірності, які часто більш корисні ніж вміст. Аналітик сигналів, який спостерігає, що батальйон А комунікує з батальйоном B щовечора о 22:00, може зробити висновок про операційне планування, може оцінити зміни змін, може навіть передбачити, коли імовірні наступальні операції.
Більше того, адміністратор може спостерігати, з яких географічних місцезнаходжень пристрої приєднуються, в який час люди входять і виходять, скільки годин вони проводять у каналі. Аналітик розвідки з доступом до цих метаданих може оцінити рівні стресу, передбачити зміни персоналу та визначити ключовий персонал просто спостерігаючи, хто зберігає присутність у яких каналах.
Федеративна модель Matrix посилює цю проблему. Система створює імплічні відносини довіри між серверами. Якщо один федеративний сервер скомпрометований, він потенційно може збирати метадані про діяльність на інших серверах. Ретельно розташована компрометація у федерації може діяти як відвідувач кількох каналів одночасно.
Проблема anti-insider архітектури
Matrix не робить серйозних спроб захистити себе від компрометації свого адміністративного персоналу. Це розумне рішення для цивільних систем, де припускається, що адміністратори є довіреними. У військових операціях це припущення хибне.
Служба розвідки може скомпрометувати адміністратора різними засобами: вербуванням, шантажем, психологічною маніпуляцією або експлуатацією особистих вразливостей. Один раз скомпрометований, цей адміністратор має повний доступ до криптографічних ключів, може змінити код для введення задних входів, може вилучити комунікації, може отруїти гарантії цілісності системи.
Архітектура не надає механізму запобігання цьому. Немає принципу проектування, який запобігав би адміністратору доступу до ключів. Немає стежу аудиту, який не міг би бути змінений кимось з адміністративними привілегіями. Немає способу виявити скомпрометованого адміністратора коротко від зовнішньої форензики.
Альтернативні підходи існують, де криптографічна цілісність системи не залежить від довіри до людей. Ці системи використовують принципово інші варіанти проектування, де архітектура сама виконує обмеження безпеки, які адміністратори не можуть обійти.
Людські фактори в проектуванні безпеки
Matrix вимагає значної експертизи для правильного розгортання та експлуатації. Система має сотні параметрів конфігурації. Одна неправильна конфігурація може створити збої безпеки, які важко виявити. Адміністратор, який не повністю розуміє федеративний протокол, може ввімкнути небезпечні конфігурації федерації. Хтось, хто не розуміє параметри ротації ключів, може встановити їх занадто агресивно або занадто консервативно, створюючи або проблеми доступності, або криптографічні ризики.
Це не критика людей, які керують Matrix. Це відображення внутрішньої складності системи. Коли система має 500 критичних варіантів конфігурації, кожен з наслідками для безпеки, ймовірність того, що кожне розгортання буде правильно реалізовувати кожен вибір, наближається до нуля.
Математика пряма. Припустимо 500 критичних параметрів конфігурації. Припустимо, що кожен має 1-відсотковий ризик неправильної конфігурації. Ймовірність того, що всі 500 будуть конфігуровані правильно, дорівнює 0.99 у степені 500, що дорівнює 0.006. Іншими словами, існує 99.4-відсоткова ймовірність того, що буде присутня принаймні одна критична неправильна конфігурація.
Відповідь Matrix на цю проблему полягала у створенні більшої документації, більшого навчання, більших освітніх ресурсів. Але фундаментальна проблема залишається: система занадто складна для надійної людської експлуатації. Військова операція не може дозволити собі розгортати системи, які виходять з ладу з 99.4-відсотковою ймовірністю через людську помилку.
Вразливість ланцюга поставок
Element, програма користувача для Matrix, залежить від зовнішної інфраструктури для правильної роботи. Оновлення розповсюджуються через Google Play та Apple App Store. Програма покладається на криптографічні сервіси Google та Apple для верифікації. Потоки аутентифікації можуть залежати від зовнішніх постачальників ідентифікації.
Це створює вразливість ланцюга поставок, яка не має паралелі в істинно суверенних системах. Якщо Google або Apple вирішать припинити підтримку програми, вона виходить з ладу. Якщо санкції застосовуються до юрисдикції, які обмежують доступ до цих сервісів, програма стає неоперабельною. Якщо служба розвідки переконає ці компанії модифікувати ланцюг оновлення, програма стає вектором компрометації.
Це не теоретичне. Технічні компанії обмежили доступ до сервісів для санкціонованих юрисдикцій. Компанії були вимушені судовими наказами модифікувати свої механізми оновлення. Інфраструктура, від якої залежить Matrix, не знаходиться під контролем розгортаючої нації та не може бути гарантована залишитися доступною.
Складність розгортання та операційні обмеження
Розгортання нового Matrix-сервера вимагає тижнів роботи. Це вимагає команд спеціалістів з глибоким розумінням протоколу, реалізації сервера Synapse, федерації, управління сертифікатами та безлічі інших операційних деталей. Один раз розгорнутий, сервер вимагає постійного моніторингу та обслуговування.
У тактичних операціях це неприйнятно. Батальйон, що працює на полі, не може чекати тижнів для розгортання комунікаційної інфраструктури. Їм потрібні системи, які можуть бути установлені за години з використанням того, яке обладнання доступне. Їм потрібні системи, які можуть бути знищені та розгорнені заново, як змінюються тактичні обставини.
Matrix не розроблена для цього операційного темпу. Піддержувальна інфраструктура вимагає інституціональних IT-ресурсів, які не завжди доступні в польових умовах.
Архітектурні різниці
Альтернативні підходи роблять різні архітектурні варіанти на кожному рівні. Криптографічне ядро є фіксованим та стабільним, розробленим до військової специфікації, а не ітеративно поліпшеним через внески спільноти открытого коду. Такі системи припускають, що деякі адміністратори скомпрометовані та розроблені функціонувати правильно незалежно. Модель розгортання використовує мінімальну інфраструктуру та мінімальні взаємозалежності. Програми розроблені спеціально для військових операцій та деградованих умов, в яких вони відбуваються.
Ці різниці не косметичні. Вони представляють принципово різні відповіді на питання про те, як спроектувати безпечну комунікацію для сторін, залучених у активний конфлікт.
Висновок
Ніщо з цього не говорить про те, що Matrix є поганою системою. Вона чудова для того, для чого була розроблена: надання зашифрованої комунікації приватності-свідомим цивільним користувачам, які користуються інтернетом. Проблема не в Matrix. Проблема в очікуванні того, що систему, розроблену для одного контексту, можна просто прийняти в зовсім іншому.
Військова комунікація у активному конфлікті вимагає іншого набору пріоритетів, інших припущень безпеки та інших операційних обмежень. Претендування на те, що цивільну комунікаційну систему можна militarizувати через конфігурацію наодиноч, це категорична помилка, яка недооцінює фундаментальні різниці між двома контекстами.
Технічний аналіз, детальний вище, це не спекуляція. Це властивості архітектури Matrix, які можна розглядати через огляд коду, моделювання загроз та операційний аналіз. Питання не в тому, чи існують ці вразливості. Питання в тому, який рівень ризику військова організація готова прийняти з огляду на її операційні вимоги.
Для одиниць, які можуть дозволити собі складність Matrix та її залежність від зовнішної інфраструктури, вона може бути адекватною. Для одиниць, що працюють у спірних середовищах з обмеженими ресурсами та високими ставками, архітектурні невідповідності стають критичними обтяженнями.
Розмова навколо безпеки військової комунікації не повинна бути про те, використовувати Matrix чи ні. Вона повинна бути про те, чи система, яку ви розгортаєте, відповідає вашому операційному середовищу. Розуміння технічних різниць є єдиним раціональним способом прийняти це рішення.