Наскрізне шифрування не вимагає від месенджера відмовлятися від централізованого зберігання. Сервер може зберігати зашифровані повідомлення для синхронізації, не володіючи секретами, потрібними для читання їхнього вмісту.
Складність обміну повідомленнями на кількох пристроях полягає у визначенні того, які пристрої авторизовані, які ключі вони отримують і чи можуть вони мати доступ до давнішої історії. Ці рішення важливіші за сам факт використання системою бази даних.
Чотири окремі операції, які часто називають «синхронізацією»
| Операція | Що вона має забезпечувати |
|---|---|
| Доставлення нових повідомлень | Передавання захищеного вмісту пристроям, авторизованим на цей момент |
| Прив’язування нового пристрою | Підтвердження того, що власник облікового запису схвалює нову кінцеву точку |
| Перенесення історії | Доступ нового пристрою до вибраного минулого вмісту й матеріалів для його розшифрування |
| Відновлення ідентичності | Відновлення або заміну ключів ідентичності, не обов’язково з відновленням історії повідомлень |
Продукт може підтримувати одну операцію, не підтримуючи всі чотири. Успішний вхід не доводить, що стару історію листування можна відновити.
Як зашифроване доставлення може підтримувати кілька пристроїв
Один із підходів передбачає окремі сеанси для кожного пристрою. Специфікація Sesame від Signal описує керування сеансами в асинхронному середовищі з кількома пристроями, зокрема додавання й видалення пристроїв та надходження повідомлень не за порядком.
Це задокументований приклад архітектури, а не універсальна вимога. Інші системи можуть шифрувати вміст один раз і розповсюджувати захищені ключі вмісту, використовувати групові механізми або поєднувати підходи. Твердження «E2EE вимагає повної копії корисного навантаження для кожного пристрою» є надто узагальненим.
Яку б архітектуру не обрали, додавання пристрою, здатного розшифровувати дані, додає кінцеву точку, яка потребує захисту. Недоглянутий ноутбук може розкрити отриманий відкритий текст, навіть якщо сервер ніколи його не бачить.
Збережений шифротекст усе одно впливає на приватність і строки зберігання
Зашифроване зберігання — не те саме, що відсутність зберігання. Провайдери можуть зберігати відомості про доставлення, записи про пристрої, часові позначки, відомості про участь або зашифровану історію повідомлень. Подробиці різняться і мають бути вказані явно.
У документації з безпеки Livara зазначено, що її ретранслятор зберігає шифротекст і службові дані для синхронізації та відновлення під час повторного підключення. У ній описано маршрутизацію, участь, часові позначки, стан доставлення та інші записи. Це не слід представляти як незадокументовану тимчасову чергу, яка обов’язково зникає, щойно кожен пристрій отримує повідомлення.
Тому конфіденційність вмісту та зберігання метаданих потребують окремих запитань. Уточнюйте, що зберігається, як довго і що змінюється після видалення даних або облікового запису; не вигадуйте строк зберігання, якщо його не підтверджено.
Що насправді відновлює механізм v7 у Livara
Livara описує v7 як зашифровану резервну копію ідентичності, захищену перед завантаженням випадковим 256-бітним ключем відновлення. Задокументоване корисне навантаження містить матеріал ключів ідентичності, а формат автентифікує його криптографічний набір, епоху ідентичності та покоління.
На тій самій сторінці зазначено, що механізм відновлює ідентичність, а не історію листування. Тому фразу відновлення не слід представляти як гарантію того, що новий пристрій зможе показати всі старі розмови.
Перш ніж замінювати пристрій або стирати з нього дані, перевірте, які поточні можливості перенесення історії та резервного копіювання справді вам доступні. Зберігайте будь-які матеріали відновлення в таємниці. Не надсилайте фразу відновлення обліковому запису підтримки й не вставляйте її на неперевіреному сайті.
Пряма секретність не стирає вхідні повідомлення авторизованого пристрою
Механізм ratchet може обмежити відомості про попередній зашифрований трафік, які розкриваються внаслідок пізнішої компрометації ключа, коли виконуються його передумови й застарілі секрети видалено. Він не може приховати відкритий текст, уже збережений кінцевою точкою, або завадити досі активному шкідливому ПЗ читати нові повідомлення.
Так само безпека після компрометації потребує відповідного свіжого оновлення після того, як зловмисник втратить доступ. Це не обіцянка, що будь-який старий планшет стає нешкідливим щоразу, коли збільшується лічильник повідомлень.
Контрольний список для безпечнішої зміни пристрою
- Зробіть перелік прив’язаних пристроїв, перш ніж додавати ще один.
- Використовуйте задокументовану процедуру прив’язування та перевірки застосунку, а не QR-код, надісланий незнайомцем.
- Перевірте на нешкідливій тестовій розмові, яку історію отримує новий пристрій.
- Підтвердьте наявність матеріалів відновлення та будь-якої окремої резервної копії історії, перш ніж стирати дані зі старого пристрою.
- Відкличте доступ пристроїв, які більше не контролюєте, і перевірте, чи отримують співрозмовники сповіщення про зміну ідентичності.
- Перегляньте локальні завантаження, сповіщення та резервні копії операційної системи на кожній кінцевій точці.
Модель загроз Livara прямо включає обмеження, пов’язані з кінцевими точками та одержувачами. Ці обмеження залишаються актуальними на будь-якому екрані. Корисна обіцянка підтримки кількох пристроїв окремо пояснює авторизацію пристроїв, збережені дані та межі відновлення.
