Взлом сервера мессенджера не обязательно означает, что все сообщения прочитаны. Результат зависит от хранимых данных, расположения ключей и уровня доступа злоумышленника. Даже при правильно реализованном сквозном шифровании текста чатов сведения об аккаунте, время, членство в группах и маршруты доставки могут быть чувствительными.
Оценивая инцидент, сначала спросите, что оказалось у злоумышленника: копия базы данных, ключи инфраструктуры, работающий сервер или система выпуска ПО? Последствия этих сценариев неодинаковы.
Украденная база данных отличается от контролируемого сервера
Злоумышленник, у которого есть только старая копия базы, ограничен записанными в ней данными. Контроль над работающим сервисом может позволить записывать новые данные, красть сессии, менять ответы или пытаться подменить ключ собеседника. Доступ к цепочке поставки ПО — другой риск: вредоносный код на конечном устройстве может видеть текст до шифрования или после расшифровки.
Поэтому утверждение «в базе нет ключа к тексту сообщений» важно, но не даёт полного ответа на все виды вторжений.
Сравнение пяти архитектурных моделей
Это учебные модели, а не рейтинг пяти продуктов. Один сервис может использовать несколько моделей для разных функций.
| Модель | Данные, доступные из базы | Важная граница |
|---|---|---|
| Сообщения и пароли в открытом виде | Контент и учётные данные читаются напрямую | Нет подходящей защиты обоих типов данных |
| Хешированные пароли, открытые сообщения | Контент читается; возможна проверка догадок о пароле | Качество хранения паролей не защищает текст чата |
| Контент зашифрован ключом сервера | Шифротекст; чтение зависит от доступа к ключу | Важно реальное разделение ключа и данных |
| Чат E2EE с резервной копией, доступной провайдеру | Текущий чат может быть защищён, но копия истории имеет отдельный путь раскрытия | Нужно изучить политику и ключ резервного копирования |
| Чат E2EE с зашифрованным восстановлением и независимым ключом | Шифротекст и операционные данные; защита контента зависит от устройства системы и защиты ключей | Устройство, фраза восстановления и проверка личности собеседника по-прежнему важны |
Шифрование диска сервера полезно при краже самого диска. Когда злоумышленник также контролирует работающий сервис или ключ расшифровки, такую же защиту нельзя считать само собой разумеющейся. Цель E2EE — отсутствие у промежуточного сервиса ключа, необходимого для чтения защищённого контента.
Что показывают метаданные?
Метаданные могут показывать, какие аккаунты общались, когда были активны, в какие группы входят и сколько данных передано. Это не текст сообщений, но эти сведения ценны для изучения сети связей или моделей активности.
Страница безопасности Livara прямо описывает хранение и обработку операционных данных, включая маршрутизацию, членство, время, размер шифротекста и статус доставки. Конфиденциальность личного контента не следует понимать как полную анонимность или отсутствие любых данных на сервере.
SRP не избавляет данные аккаунта от риска подбора пароля
SRP — способ доказать знание пароля, не отправляя непосредственно сам пароль. Сервер всё равно хранит проверочные данные — verifier. Раздел безопасности RFC 5054 объясняет, что кража verifier может сделать возможной словарную атаку для подбора пароля.
Поэтому «пароль не передаётся по сети» отличается от «нет никаких связанных с паролем данных, которые можно украсть». Уникальный и сильный пароль, защита устройства и правильное реагирование на инцидент по-прежнему нужны. SRP также не заменяет шифрование контента или защиту сессии входа.
Какие границы заявлены для Livara?
Документ безопасности Livara описывает LVR1 для личных сообщений и LGS1 для защищённых групп. Защита группы зависит от её фактического состояния; несовместимая устаревшая группа не должна получать метку E2EE. Публичные каналы находятся за пределами этой границы конфиденциальности.
Тот же документ представляет восстановление v7 как зашифрованный пакет идентичности, защищённый до загрузки. Этот процесс возвращает криптографическую идентичность, а не историю чатов. Раскрытие фразы восстановления или устройства, на котором находятся ключи, — иной сценарий, чем просто кража базы данных.
Это опубликованные описания продукта, а не результат независимого аудита в данной статье. Само по себе упоминание AES или ML-KEM также не доказывает правильность управления ключами и реализации приложения.
Какие вопросы задавать при сообщении об инциденте?
- Какой период времени и какие системы затронуты? Неясной фразы «данные пользователей» недостаточно.
- Были доступны открытый текст, файлы, ключи, verifier, сессии входа или только шифротекст?
- Мог ли злоумышленник изменить сервис или ПО, доставляемое пользователям?
- Какие действия нужны через официальные каналы: завершение сессий, смена пароля, обновление или проверка личности собеседника?
- Может ли рекомендованное восстановление уничтожить локальную историю? Прочитайте ограничения до удаления приложения.
Не используйте ссылку из анонимного сообщения для «срочного подтверждения аккаунта». Самостоятельно откройте официальный адрес и прочитайте объявление. Модель угроз Livara помогает понять общие границы; масштаб реального инцидента должен определяться доказательствами именно этого инцидента.
