Окремий ключ для файлу не означає одноразового перегляду або можливості забрати копію в одержувача.
Для захисту вкладення месенджер може зашифрувати файл на пристрої відправника випадковим ключем, завантажити зашифровану версію й передати ключ файлу одержувачу всередині повідомлення з наскрізним шифруванням. Цей підхід іноді називають конвертним шифруванням: великий файл і невеликі дані, потрібні для його відкриття, проходять різними, але пов’язаними шляхами.
Це пояснення стосується вкладень у розмові з E2EE; надсилання файлу в будь-якій програмі або каналі будь-якого типу не обов’язково забезпечує такий самий захист.
Шлях приватної фотографії від пристрою до одержувача
- Пристрій відправника створює ключ вмісту для файлу.
- Файл шифрується з автентифікацією; одержувач має виявляти несанкціоновані зміни даних.
- Зашифрована версія розміщується в сервісі зберігання файлів.
- Адреса або ідентифікатор файлу та потрібний ключ надсилаються одержувачу в захищеному повідомленні.
- Пристрій одержувача отримує файл, перевіряє його й лише потім відкриває.
Документація з безпеки Livara описує випадковий ключ для кожного вкладення та його передавання в сеансі обміну повідомленнями. Ця стаття пояснює заявлену архітектуру, а не результати аудиту реалізації.
«Окремий ключ файлу» не означає «файл відкривається лише один раз»
Ключ, створений для файлу, може знадобитися для багаторазового читання того самого файлу. Окремий ключ не означає його негайного знищення після першого перегляду, автоматичного видалення файлу чи заборони збереження одержувачем.
Одноразове використання ключа повідомлення та використання ключа вмісту для вкладення — також різні поняття. Не можна виводити такі функції, як View Once або зникаючі повідомлення, лише з назви алгоритму.
Чому важливі і ключ, і nonce?
AES-GCM забезпечує не тільки конфіденційність, а й перевірку автентичності даних; проте його потрібно застосовувати правильно. Стандарт NIST SP 800-38D описує правила GCM. Повторне використання поєднання ключа та nonce для різних даних може поставити безпеку під загрозу.
Практичний висновок для користувача: напису «AES-256» недостатньо. Потрібно також вивчити керування ключами, генерування випадкових значень, перевірку файлів та оброблення помилок. Зміна одного байта має призводити до відхилення недійсного файлу, а не до показу зміненого вмісту як неушкодженого файлу.
Що бачать одержувач, сервер і програма галереї?
| Місце | Питання безпеки |
|---|---|
| Сервіс зберігання файлів | Чи має він лише зашифровані байти, чи йому доступний і ключ? |
| Повідомлення з ключем | Чи захищені ключ, назва файлу та його опис у розмові з E2EE? |
| Пристрій одержувача | Де залишається відкритий файл: у пам’яті, кеші чи галереї? |
| Хмарна резервна копія | Чи потрапляє збережена копія до резервної копії фотографій і як захищено цю резервну копію? |
Шифрування під час передавання не контролює копію, яку одержувач зберігає в галереї. Перед надсиланням конфіденційного документа перевірте також зайві частини зображення, написи на тлі та відомості про місцеперебування у файлі.
Чим відрізняється файл у приватній групі?
Кількість уповноважених власників ключа збільшується. Livara описує захист вкладень сумісних приватних груп у режимі E2EE в LGS1; це твердження не слід поширювати на публічні канали. Кожен учасник, який отримав файл, може зберегти копію. Видалення учасника чи зміна ключа для майбутнього обміну не забирає його попередню копію.
Контрольний список для надсилання конфіденційного файлу
- Ще раз перевірте простір спілкування та одержувачів.
- Якщо особа співрозмовника важлива, підтвердьте відбиток ключа через довірений канал.
- Надсилайте лише потрібну інформацію; повна фотографія документа потрібна не завжди.
- Узгодьте з одержувачем збереження в галереї, автоматичне завантаження та хмарні резервні копії.
- Не залишайте розшифрований файл на спільному або незаблокованому пристрої.
Поширені запитання
Чи гарантує окремий ключ файлу безпечне надсилання?
Ні. Потрібні також належний стан пристроїв, автентифікація одержувача та правильна реалізація. Читайте модель загроз Livara разом зі специфікаціями шифрування.
Чи має зображення в публічному каналі такий самий захист?
За заявленими межами Livara, канали публічні та доступні для читання; для них не обіцяють конфіденційності приватних вкладень.
Чи достатньо самого посилання на файл?
Це залежить від побудови сервісу. Перевіряйте посилання, ключ і дозвіл на доступ окремо; сама лише довга або випадкова URL-адреса не доводить наявності E2EE.
