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