Сквозное шифрование не требует, чтобы мессенджер отказывался от централизованного хранения. Сервер может хранить зашифрованные сообщения для синхронизации, не располагая секретами, необходимыми для чтения их содержимого.
Сложность обмена сообщениями на нескольких устройствах заключается в определении того, какие устройства авторизованы, какие ключи они получают и могут ли они получить доступ к старой истории. Эти решения важнее, чем сам факт использования системой базы данных.
Четыре разные операции, которые часто называют «синхронизацией»
| Операция | Что она должна обеспечивать |
|---|---|
| Доставка новых сообщений | Передачу защищённого содержимого устройствам, авторизованным в данный момент |
| Привязка нового устройства | Подтверждение того, что владелец аккаунта одобряет новую конечную точку |
| Перенос истории | Доступ нового устройства к выбранному прошлому содержимому и материалам для его расшифрования |
| Восстановление идентичности | Восстановление или замену ключей идентичности, не обязательно с восстановлением истории сообщений |
Продукт может поддерживать одну операцию, не поддерживая все четыре. Успешный вход не доказывает, что старую историю переписки можно восстановить.
Как зашифрованная доставка может поддерживать несколько устройств
Один из подходов предусматривает отдельные сеансы для каждого устройства. Спецификация Sesame от Signal описывает управление сеансами в асинхронной среде с несколькими устройствами, включая добавление и удаление устройств и поступление сообщений не по порядку.
Это документированный пример архитектуры, а не универсальное требование. Другие системы могут шифровать содержимое один раз и распространять защищённые ключи содержимого, использовать групповые механизмы или сочетать подходы. Утверждение «E2EE требует полного дубликата полезной нагрузки для каждого устройства» слишком обобщённое.
Какую бы архитектуру ни выбрали, добавление устройства, способного расшифровывать данные, добавляет конечную точку, которую нужно защищать. Ноутбук, за которым не следят, может раскрыть полученный открытый текст, даже если сервер никогда его не видит.
Хранение шифротекста всё равно влияет на приватность и сроки хранения
Зашифрованное хранение — не то же самое, что отсутствие хранения. Провайдеры могут сохранять сведения о доставке, записи об устройствах, временные метки, сведения об участии или зашифрованную историю сообщений. Детали различаются и должны указываться явно.
В документации по безопасности Livara говорится, что её ретранслятор хранит шифротекст и служебные данные для синхронизации и восстановления при повторном подключении. В ней описаны маршрутизация, участие, временные метки, состояние доставки и другие записи. Это не следует представлять как недокументированную временную очередь, которая обязательно исчезает, как только все устройства получают сообщение.
Поэтому конфиденциальность содержимого и хранение метаданных требуют отдельных вопросов. Уточняйте, что сохраняется, как долго и что меняется при удалении данных или аккаунта; не придумывайте срок хранения, если он не подтверждён.
Что на самом деле восстанавливает механизм v7 в Livara
Livara описывает v7 как зашифрованную резервную копию идентичности, защищённую перед загрузкой случайным 256-битным ключом восстановления. Документированная полезная нагрузка включает материал ключей идентичности, а формат аутентифицирует её криптографический набор, эпоху идентичности и поколение.
На той же странице указано, что механизм восстанавливает идентичность, а не историю переписки. Поэтому фразу восстановления нельзя представлять как гарантию того, что новое устройство сможет показать все старые разговоры.
Прежде чем заменять устройство или стирать с него данные, проверьте, какие актуальные возможности переноса истории и резервного копирования действительно вам доступны. Храните любые материалы восстановления в тайне. Не отправляйте фразу восстановления аккаунту поддержки и не вставляйте её на непроверенном сайте.
Прямая секретность не стирает входящие сообщения авторизованного устройства
Механизм ratchet может ограничить сведения о прошлом зашифрованном трафике, раскрываемые при последующей компрометации ключа, если выполняются его предпосылки и устаревшие секреты удалены. Он не может скрыть открытый текст, уже сохранённый конечной точкой, или помешать всё ещё активному вредоносному ПО читать новые сообщения.
Аналогично, безопасность после компрометации требует соответствующего свежего обновления после того, как злоумышленник потеряет доступ. Это не обещание, что любой старый планшет становится безвредным всякий раз, когда увеличивается счётчик сообщений.
Контрольный список для более безопасной смены устройства
- Проведите инвентаризацию привязанных устройств, прежде чем добавлять ещё одно.
- Используйте документированную процедуру привязки и проверки приложения, а не QR-код, присланный незнакомцем.
- Проверьте на безобидной тестовой переписке, какую историю получает новое устройство.
- Подтвердите наличие материалов восстановления и любой отдельной резервной копии истории, прежде чем стирать данные со старого устройства.
- Отзовите доступ устройств, которые больше не контролируете, и проверьте, получают ли собеседники уведомление о смене идентичности.
- Проверьте локальные загрузки, уведомления и резервные копии операционной системы на каждой конечной точке.
Модель угроз Livara явно включает ограничения, связанные с конечными точками и получателями. Эти ограничения остаются актуальными на любом экране. Полезное обещание поддержки нескольких устройств отдельно объясняет авторизацию устройств, хранимые данные и границы восстановления.
