Копия диска, управление работающим сервером и доступ к телефону — три разных сценария; одной общей гарантии для них недостаточно.
Если сервер мессенджера захвачен, точный ответ на вопрос «что будет раскрыто?» зависит от сохранённых данных, расположения ключей и типа доступа атакующего. Получение копии диска не равнозначно контролю работающего сервиса и канала распространения приложения.
В статье рассматривается гипотетический сценарий на основе публичной документации 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 из этого эксперимента. Успешный результат не гарантирует устойчивость всего продукта к захвату инфраструктуры.
Что делать при оценке или реальном инциденте?
- Зафиксируйте тип доступа и подтверждённые сведения; не приравнивайте слухи о сбое к установленному инциденту безопасности.
- Проверьте версию приложения и состояние шифрования именно этой беседы.
- Проверяйте изменения идентичности, участников группы и неизвестные сеансы через официальный канал.
- Не передавайте секрет восстановления, пароль или личное содержимое незнакомцам для «проверки безопасности».
- При серьёзном риске или юридическом вопросе обратитесь к соответствующему специалисту и не совершайте необратимых действий на основании одной статьи.
Надёжный вывод должен указывать, какие данные защищены, в какой версии и от какого доступа. Фраза «даже при изъятии сервера ничего не случится» не заменяет такого ответа.
