Відновлення криптографічної ідентичності, повторний вхід до облікового запису та відновлення історії чатів — три різні завдання. Згідно з документацією з безпеки Livara, формат v7 використовується для відновлення криптографічної ідентичності; сам цей формат не відновлює історію чатів.
Також цю архітектуру не слід описувати як «повну відсутність хмарних резервних копій». Поточний документ каже, що матеріали ідентичності шифруються на пристрої, а потім завантажуються як зашифрована резервна копія. Важливо розрізняти зберігання читабельного ключа на сервері та зберігання зашифрованої копії, для відкриття якої потрібен ключ відновлення.
Троє дверей із різними ключами
| Операція | Мета | Чому цього недостатньо? |
|---|---|---|
| Вхід до облікового запису | Підтвердити право доступу до облікового запису сервісу | Не обов’язково надає ключ для розшифрування попередніх повідомлень |
| Відновлення ідентичності | Повернути доступ до матеріалів криптографічної ідентичності | Саме по собі не доводить наявності або відновлення всіх повідомлень |
| Відновлення історії | Повернути потрібні повідомлення та вкладення | Окрім ключа потрібні самі дані й підтримуваний спосіб відновлення |
Це розмежування запобігає дорогій помилці: стиранню старого телефона з думкою, що знання пароля для входу достатньо для повернення всіх розмов.
Що саме каже документація v7?
Сторінка безпеки Livara пояснює, що ключі узгодження й підпису P-256 та початкове значення ML-KEM шифруються на пристрої випадковим 256-бітним ключем відновлення. В описі формату v7 також автентифікуються набір алгоритмів, епоха ідентичності та покоління. Це документ виробника, а не сам по собі незалежний аудит реалізації.
Модель загроз Livara визначає фразу відновлення як необхідну для відкриття резервної копії ключів. Із цього опису не слід вгадувати точний алгоритм перетворення фрази на ключ або робити висновок про пряме відтворення всіх ключів. Практичні подробиці треба звіряти з версією застосунку та посібником саме до неї.
Чому функція виведення ключів не робить слабку фразу сильною?
Довжина виходу функції — не те саме, що непередбачуваність входу. RFC 5869 прямо зазначає, що HKDF концентрує наявну ентропію, але не збільшує її. Тому не можна стверджувати, що будь-яка довільна фраза після обробки HKDF автоматично отримує повну 256-бітну стійкість.
Не скорочуйте, не переписуйте й не замінюйте передбачуваним реченням фразу, створену офіційним процесом застосунку. Не надсилайте її жодній людині, боту підтримки чи невідомій формі.
Перед заміною або очищенням телефона
- Переконайтеся в застосунку, що саме збережено в резервній копії: ідентичність, історію чи обидва компоненти окремими способами.
- Зберігайте фразу відновлення в безпечному місці незалежно від цього телефона; вважайте доступ інших людей до неї серйозним ризиком.
- Прочитайте посібник із відновлення для поточної версії. Саме повідомлення «вхід успішний» не означає повного відновлення.
- Якщо підтримується спосіб перевірки відновлення, спочатку випробуйте його на нечутливих даних, не стираючи єдину наявну копію.
- Після перенесення перевірте потрібні розмови й файли; лише тоді вирішуйте, чи можна відмовитися від старого пристрою.
Що робити, якщо в мене немає фрази відновлення?
Якщо ви ще маєте авторизований пристрій, перевіряйте лише офіційні шляхи, доступні в самому застосунку; не припускайте можливості створення нової резервної копії без перевірки версії. Якщо втрачено і пристрій, і фразу, документ Livara не обіцяє відновлення ключів. Жоден сервіс «гарантованого розшифрування» не скасовує цього обмеження.
Починайте план перенесення облікового запису із запитання «Які дані, яким ключем і з якої резервної копії повернуться?», а не з припущення, що повторний вхід дорівнює поверненню всіх чатів.
