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