Отдельный ключ для файла не означает однократный просмотр или возможность забрать копию у получателя.
Для защиты вложения мессенджер может зашифровать файл на устройстве отправителя случайным ключом, загрузить зашифрованную версию и передать ключ файла получателю внутри сообщения со сквозным шифрованием. Такой подход иногда называют конвертным шифрованием: большой файл и небольшие данные, необходимые для его открытия, идут разными, но связанными путями.
Это объяснение относится к вложениям в разговоре с E2EE; отправка файла в любом приложении или канале любого типа не обязательно обеспечивает такую же защиту.
Путь личной фотографии от устройства до получателя
- Устройство отправителя создаёт ключ содержимого для файла.
- Файл шифруется с аутентификацией; получатель должен обнаруживать несанкционированные изменения данных.
- Зашифрованная версия размещается в сервисе хранения файлов.
- Адрес или идентификатор файла и нужный ключ отправляются получателю в защищённом сообщении.
- Устройство получателя загружает файл, проверяет его и затем открывает.
Документация по безопасности Livara описывает случайный ключ для каждого вложения и его передачу в сеансе обмена сообщениями. Эта статья объясняет заявленную архитектуру, а не результаты аудита реализации.
«Отдельный ключ файла» не означает «файл открывается только один раз»
Ключ, созданный для файла, может понадобиться для многократного чтения того же файла. Отдельный ключ не означает его немедленное уничтожение после первого просмотра, автоматическое удаление файла или запрет сохранения получателем.
Однократное использование ключа сообщения и использование ключа содержимого для вложения — тоже разные понятия. Нельзя выводить такие функции, как View Once или исчезающие сообщения, только из названия алгоритма.
Почему важны и ключ, и nonce?
AES-GCM обеспечивает не только конфиденциальность, но и проверку подлинности данных; однако его необходимо применять правильно. Стандарт NIST SP 800-38D описывает правила GCM. Повторное использование сочетания ключа и nonce для разных данных может поставить безопасность под угрозу.
Практический вывод для пользователя: надписи «AES-256» недостаточно. Нужно также изучить управление ключами, генерацию случайных значений, проверку файлов и обработку ошибок. Изменение одного байта должно приводить к отклонению недействительного файла, а не к показу изменённого содержимого как неповреждённого файла.
Что видят получатель, сервер и приложение галереи?
| Место | Вопрос безопасности |
|---|---|
| Сервис хранения файлов | Есть ли у него только зашифрованные байты или ему доступен и ключ? |
| Сообщение с ключом | Защищены ли ключ, имя файла и его описание в разговоре с E2EE? |
| Устройство получателя | Где остаётся открытый файл: в памяти, кеше или галерее? |
| Облачная резервная копия | Попадает ли сохранённая копия в резервную копию фотографий и как защищена эта резервная копия? |
Шифрование при передаче не контролирует копию, которую получатель сохраняет в галерее. Перед отправкой конфиденциального документа проверьте также ненужные части изображения, надписи на заднем плане и сведения о местоположении в файле.
Чем отличается файл в закрытой группе?
Число уполномоченных владельцев ключа увеличивается. Livara описывает защиту вложений совместимых закрытых групп в режиме E2EE в LGS1; это утверждение нельзя распространять на публичные каналы. Любой участник, получивший файл, может сохранить копию. Удаление участника или смена ключа для будущего обмена не отбирает у него прежнюю копию.
Контрольный список для отправки конфиденциального файла
- Ещё раз проверьте пространство общения и получателей.
- Если личность собеседника важна, подтвердите отпечаток ключа по доверенному каналу.
- Отправляйте только нужную информацию; полная фотография документа нужна не всегда.
- Договоритесь с получателем о сохранении в галерее, автоматическом скачивании и облачных резервных копиях.
- Не оставляйте расшифрованный файл на общем или незаблокированном устройстве.
Частые вопросы
Гарантирует ли отдельный ключ файла безопасную отправку?
Нет. Необходимы также исправное и защищённое состояние устройств, аутентификация получателя и правильная реализация. Читайте модель угроз Livara вместе со спецификациями шифрования.
Имеет ли изображение в публичном канале ту же защиту?
Согласно заявленным границам Livara, каналы публичны и доступны для чтения; для них не обещается конфиденциальность закрытых вложений.
Достаточно ли одной ссылки на файл?
Это зависит от устройства сервиса. Проверяйте ссылку, ключ и разрешение на доступ отдельно; сама по себе длинная или случайная URL-ссылка не доказывает наличие E2EE.
