Копія диска, контроль працюючого сервера та доступ до телефона — три різні сценарії; однієї загальної гарантії для них недостатньо.
Якщо сервер месенджера захоплено, точна відповідь на запитання «що буде розкрито?» залежить від збережених даних, розташування ключів і типу доступу нападника. Отримати копію диска — не те саме, що контролювати працюючий сервіс і шлях розповсюдження застосунку.
Ця стаття розглядає гіпотетичний сценарій на основі публічної документації Livara. Вона не стверджує нічого про розташування дата-центрів Livara, факт вилучення чи гарантовану роботу сервісу під час відключення інтернету. Шифрування вмісту, доступність мережі й безпека інфраструктури — окремі питання.
Спочатку визначимо тип доступу
Збережена копія сервера: Нападник отримує доступ до файлів, бази даних або резервних копій, наявних у цьому знімку. Якщо приватний вміст правильно зашифровано на пристрої, а сервер не має ключа розшифрування, саме володіння цією копією не розкриває текст листування.
Активний контроль сервісу: Окрім читання наявних даних, нападник може блокувати деякі запити, повертати застарілі дані чи змінювати поведінку підконтрольних компонентів. У цьому сценарії більшого значення набувають перевірка особи співрозмовника, контроль версій і цілісність клієнта.
Одночасний доступ до пристрою: Розблокований телефон, шкідливе ПЗ або читабельна копія в учасника розмови можуть розкрити вміст зовсім іншим шляхом. Модель загроз Livara також не гарантує захист розблокованого чи зараженого пристрою.
Які дані видно на сервері згідно з документацією Livara?
Сторінка безпеки Livara, позначена версією 0.1.68, відокремлює вміст особистих чатів під LVR1 і сумісних приватних груп під LGS1 від операційних відомостей. Там само прямо сказано, що старі несумісні групи залишаються поза E2EE; отже, потрібно перевіряти стан конкретної розмови.
| Категорія даних | Задокументована межа й можливий наслідок |
|---|---|
| Текст і вкладення захищеної розмови | Сервер зберігає зашифровану копію; для читання потрібен відповідний ключ |
| Метадані зв’язку | Сервісу доступні такі відомості, як учасники, час, розмір і стан доставлення |
| Склад групи | Належить до операційних відомостей і повноважень сервера |
| Публічний канал | Вміст є загальнодоступним і читабельним для сервера |
| Пакет відновлення ідентичності v7 | Шифрується до завантаження й потребує окремого секрету відновлення |
| Необов’язковий запис на сервері | Відрізняється від режиму E2EE позначкою REC; наскрізну конфіденційність для нього припускати не слід |
Код LSS1 для захисту метаданих згадується в документації, але не підключений до звичайного надсилання повідомлень. Наявність назви протоколу в проєкті не доводить, що він активний у всіх комунікаціях.
Таблиця описує заяви про продукт, а не результати реального випробування під час вилучення чи незалежного аудиту всіх копій бази даних.
Наскільки важливими можуть бути метадані?
Відомості про зв’язки між людьми, час і участь у групах можуть бути чутливими навіть без тексту повідомлень. Проте фраза «увесь граф зв’язків розкривається назавжди» є неточною без знання строків зберігання, охоплення журналів і отриманої копії даних.
Для справжньої оцінки слід запитати, які поля збиралися, як довго зберігалися та які резервні копії доступні. Саме шифрування вмісту не визначає політику зберігання даних. Також з архітектури одного месенджера не випливає, що всі месенджери неодмінно зберігають однакові метадані.
Чим контроль сервера загрожує майбутнім повідомленням?
Під час перевірки безпеки потрібно окремо тестувати зміну списку учасників, надання іншого ключа ідентичності, перешкоджання оновленням і доставлення шкідливого клієнта. Вплив кожного випадку залежить від перевірок на боці клієнта, відображення змін і підтвердження особи.
Без тестування реалізації не можна стверджувати, що кожен захоплений сервер обов’язково здатен додати прихованого учасника; як не можна стверджувати й того, що активний контроль сервера ні на що не впливає. У чутливих розмовах слід перевіряти несподівані зміни ідентичності чи складу учасників. Порівняння відбитка ключа зі співрозмовником незалежним довіреним каналом дає більше інформації, ніж сама довіра до відображуваного імені.
Якщо нападник змінить код, що виконується на пристрої, він може побачити текст до шифрування. Саме тому безпека розповсюдження й оновлення застосунку є частиною цього сценарію, а не питанням поза криптографією.
Що додає постквантовий захист?
Стандарт NIST FIPS 203 для ML-KEM допомагає встановити спільний секрет. Правильне застосування в гібридній конструкції може зменшити ризик деяких майбутніх атак на обмін ключами. Ця властивість не замінює безпеку пристрою, обмежене зберігання метаданих чи контроль доступу до сервера.
Proof Lab також демонструє лише деякі локальні операції P-256, HKDF і AES-GCM та залишає повну композицію LVR1/LGS1 поза цим експериментом. Успішний результат не гарантує стійкості всього продукту до захоплення інфраструктури.
Що робити під час оцінки або реального інциденту?
- Зафіксуйте тип доступу й підтверджені відомості; не прирівнюйте чутки про збій до встановленого інциденту безпеки.
- Перевірте версію застосунку та стан шифрування саме цієї розмови.
- Перевіряйте зміни ідентичності, учасників групи й невідомі сеанси офіційним шляхом.
- Не передавайте секрет відновлення, пароль чи приватний вміст незнайомцям для «перевірки безпеки».
- За серйозного ризику чи юридичного питання зверніться до відповідного фахівця й не вчиняйте незворотних дій на підставі однієї статті.
Надійний висновок має визначати, які дані захищено, у якій версії та від якого доступу. Фраза «навіть якщо сервер вилучать, нічого не станеться» не замінює такої відповіді.
