Зашифрованное хранение отделяет байты файла от возможности расшифровки, но получатели, метаданные и локальные копии остаются частью модели угроз.
Вложение со сквозным шифрованием можно хранить на сервере, не предоставляя ему исходный файл. Распространённая схема шифрует файл на устройстве отправителя свежим ключом содержимого, загружает шифротекст и передаёт ключ нужным получателям внутри аутентифицированного зашифрованного сообщения.
Такое разделение полезно, но «хранилище с нулевым знанием» — не полная спецификация. Всё равно нужно выяснять, как обрабатываются ключи, ссылки на файлы, имена файлов, контроль доступа и скачанные копии.
Жизненный цикл вложения
- Подготовить файл. Отправитель выбирает фото, видео или документ. Удаление метаданных или перекодирование — отдельный этап; само шифрование не удаляет EXIF и свойства документа.
- Создать материал для шифрования. Безопасная реализация генерирует требуемые ключи и nonce согласно выбранной схеме.
- Зашифровать до загрузки. Служба хранения получает зашифрованные байты, а не исходное содержимое.
- Передать аутентифицированную ссылку. Зашифрованное сообщение содержит нужную получателям информацию: например, указатель местоположения файла, ключ расшифровки и соответствующие метаданные целостности.
- Получить и проверить. Клиент получателя скачивает blob и проверяет аутентификацию, прежде чем считать результат корректным содержимым.
- Управлять локальными копиями. Просмотр, экспорт, редактирование или сохранение в галерею могут создать копии за пределами исходной границы зашифрованного хранения.
Ключ может проходить через инфраструктуру того же провайдера в зашифрованном конверте. Название «внеполосная передача» может вводить в заблуждение: ключ логически отделён от хранения blob, но не обязательно доставляется по независимому каналу связи.
Что добавляет аутентифицированное шифрование
Схема аутентифицированного шифрования защищает конфиденциальность и обнаруживает несанкционированные изменения в пределах аутентифицируемой области. Спецификация GCM NIST определяет одну такую конструкцию и её требования. Правильная работа с ключом/nonce и проверка результата аутентификации обязательны; известное название алгоритма не делает безопасной каждую реализацию.
Приложению также нужно связать файл с правильными сообщением и беседой. Корректный зашифрованный blob сам по себе не доказывает, что он относится именно к этому чату. Идентификаторы файлов, ожидаемый размер, порядок фрагментов и метаданные вложения требуют подходящей аутентифицированной конструкции.
Что служба хранения всё ещё может узнать
| Информация | Скрывает ли её одно лишь шифрование содержимого? |
|---|---|
| Исходные байты файла | Оно предназначено для их сокрытия от сторон без ключа |
| Примерный размер зашифрованных данных | Обычно нет |
| Время загрузки и скачивания | Обычно нет |
| Какой аккаунт запрашивает файл | Зависит от маршрутизации и контроля доступа |
| Имя файла и подпись | Только если протокол защищает и их |
| Копия, сохранённая получателем | Нет; получатель уже имеет доступ к открытому содержимому |
Контроль доступа важен даже для зашифрованных blob. Он может ограничивать нежелательное скачивание, злоупотребления и раскрытие идентификаторов. Шифрование не заменяет авторизацию, политики хранения и доступность.
Большим файлам нужно больше, чем лозунг
Система для больших файлов может передавать данные потоком или делить их на аутентифицированные фрагменты. Это может снизить расход памяти, но необходимо определить нумерацию фрагментов, итоговую длину, повторные попытки и обработку усечения. Не выдумывайте показатели производительности и не утверждайте, что включение файла в сообщение обязательно вызывает «разрастание состояния ratchet»: такие результаты зависят от реализации.
Полезная проверка включает корректный файл, изменённый байт, усечённое скачивание, фрагмент с изменённым порядком и попытку неавторизованного получения. Проводите такие тесты только в разрешённой тестовой среде с нечувствительными файлами. Фиксируйте, отклоняет ли клиент некорректные данные до открытия.
Что документирует Livara
Страница безопасности Livara описывает шифрование перед загрузкой, случайный ключ для каждого файла, передаваемый внутри защищённой сессии, и защиту имён файлов и подписей в беседах с активным E2EE, включая совместимые приватные группы. Старые несовместимые группы явно исключены из этого охвата. Защищённые беседы отделены от публичных вещательных каналов. Это документированные заявления о продукте, а не новый аудит реализации в этой статье.
Модель угроз также признаёт, что получатель или скомпрометированное устройство могут раскрыть читаемое содержимое. Поэтому зашифрованное хранение не может обещать исчезновение изображения со всех устройств при удалении его сообщения в чате.
Вопросы перед передачей чувствительных файлов
Проверьте, поддерживает ли тип беседы E2EE, доверяете ли вы всем предполагаемым получателям и содержит ли сам файл идентифицирующие метаданные. Отдельно изучите автоматическое сохранение в галерею и облачное резервное копирование фото. Для документа подумайте, следует ли удалить комментарии, историю правок или встроенные свойства перед отправкой.
Наконец, разберитесь с удалением и восстановлением. Удаление blob с сервера может остановить будущее скачивание, но не отозвать уже имеющуюся копию получателя. Потеря необходимого ключа может сделать оставшийся зашифрованный файл нечитаемым. Хорошая схема вложений ясно объясняет оба исхода.
