Чому мобільний HD-гаманець втрачає доступ до коштів
Мобільний HD-гаманець тримає весь доступ до коштів в одному кореневому секреті: з нього детерміновано виводиться ланцюжок ключів на адреси, а мнемонічна фраза залишається єдиним носієм, який можна відновити на іншому пристрої.
Поки застосунок живе на одному телефоні, схема непомітна. Збій проявляється в момент відновлення або оновлення і виглядає як зниклий баланс, хоча кошти нікуди не зникали.
Найчастіша причина — розсинхронізація індексу адрес. Гаманець видає користувачеві нову адресу для отримання, але під час відновлення сканує менше позицій, ніж реально використано, і зупиняється на першому порожньому проміжку.
Транзакції в мережі є, а в інтерфейсі нуль: користувач сприймає це як втрату доступу і приходить із претензією до продукту, а не до власної резервної копії.
Другий клас збоїв — повторно використаний ланцюжок ключів.
Перевстановлення поверх старого профілю, дві копії застосунку, що пишуть в одне локальне сховище, або резервна копія, знята не в повному вигляді, призводять до того, що адреси розходяться, а частина історії залишається за межами поточної гілки.
Галузева норма тут — стандарти родини BIP: вони задають правила виведення, але не захищають від помилок у їх застосуванні.
Третій збій — некоректна міграція між версіями сховища. Змінюється схема шифрування або шлях виведення ключів, старі записи не читаються, застосунок піднімається з порожнім профілем і не повідомляє про це явно. Розбираємо нижче, як ці сценарії закриваються на рівні архітектури зберігання й обліку адрес.
Що змінює переробка архітектури гаманця
Переробка архітектури гаманця змінює те, як HD-гаманець зберігає ключовий матеріал, відновлює стан і синхронізується з мережею. Результат вимірюється в хвилинах простою і в кількості сценаріїв, які перестають бути можливими.
Відновлення доступу за лічені хвилини замість листування з підтримкою
В основі — мнемонічна фраза і детерміноване виведення адрес: користувач вводить її на новому пристрої й отримує той самий набір адрес без звернення до підтримки. Час відновлення доступу падає з годин листування до кількох хвилин. Перевіряємо:
- Перевстановлення й введення фрази повертають усі адреси та історію операцій; сценарій закритий автотестом на чистому пристрої.
- Інструкція для випадку «загубив телефон» лежить у застосунку, а не в листуванні з підтримкою.
- Після повернення в мережу пропущені блоки наздоганяються без ручного втручання.
Усунений клас відмов: витік ключа під час бекапу
Резервне копіювання перестає копіювати приватні ключі: зберігається лише зашифрований контейнер або фраза, яку користувач зберігає окремо. Це знімає цілий клас відмов — компрометацію ключа через хмарні копії та системні знімки пристрою.
Вимоги звіряємо із зовнішніми керівництвами з безпеки, наприклад OWASP Mobile Application Security. Чек-ліст:
- Ключі не потрапляють у хмарні копії та системні знімки.
- Стійкість шифрування перевірена тестами на слабкі й повторювані паролі.
- Відкат на попередню версію застосунку не ламає доступ до створених адрес.
Режими зберігання ключів: порівняння підходів
Режим зберігання приватних ключів задає модель загроз: де живе ключ, хто ним підписує і що станеться в разі компрометації пристрою. Нижче — п’ять варіантів, між якими реально обирають під час проєктування HD-гаманця.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ключ у пам’яті застосунку | Прототип, закритий контур, немає вимог до стійкості | Ключ потрапляє в дамп пам’яті, немає захисту в разі втрати пристрою |
| Ключ у захищеному сховищі пристрою | Масовий гаманець: ключ прив’язаний до пристрою | Відновлення лише за мнемонічною фразою, прив’язка до платформи |
| Винесений підписувач | Підпис виноситься в окремий компонент | Потрібен захищений канал, зростає затримка підпису |
| Мультипідпис із розподілом ролей | Корпоративні сценарії, одноосібне розпорядження виключено | Складніший облік ролей і відновлення в разі втрати частини |
| Режим лише перегляду | Спостереження за балансом та історією без підпису | Немає підпису всередині застосунку, залежність від підписувача |
Коли який режим виправданий
Споживчому гаманцю достатньо ключа в захищеному сховищі пристрою та режиму спостереження на другому пристрої. Корпоративні схеми вимагають мультипідпису з розподілом ролей, сервіси з автоматичним виведенням коштів — винесеного підписувача. Режими комбінуються: перегляд без права підпису видають підтримці та аналітиці.
Ціна помилки у виборі режиму
Помилка не видна в тестах: застосунок працює, транзакції проходять. Вона розкривається в момент інциденту — під час втрати пристрою, витоку резервної копії або звільнення співробітника з ключем.
Переробка зачіпає деривацію адрес і міграцію вже створених гаманців, тому режим фіксують до першого релізу.
Етапи робіт: аудит, схема ключів, перевірка, передача
Порядок робіт вибудуваний так, щоб незворотні частини — схема ключів і модуль підпису — проєктувалися вже після того, як ми розуміємо поточне сховище та вимоги до відновлення.
Нижче — послідовність, за якою йде проєкт: кожен етап закінчується артефактом, який можна перевірити до переходу до наступного.
- Аудит гаманця. Розбираємо поточне сховище секретів, спосіб отримання адрес, журнали операцій і те, як сьогодні відновлюють доступ у разі втрати пристрою. На виході — карта вузьких місць і перелік рішень, які не можна змінювати після релізу.
- Схема ключів. Фіксуємо дерево ключів і шляхи їх отримання, розподіляємо гілки під мережі та типи адрес, описуємо порядок виведення мнемоніки й правила її зберігання. Тут же визначаємо, які ключі взагалі не покидають захищену область пристрою.
- Модуль підпису та політики доступу. Реалізуємо підпис транзакцій усередині ізольованого модуля, налаштовуємо ліміти, підтвердження великих операцій і розмежування прав між ролями. Журнал підпису не містить секретів, але дозволяє відновити хронологію подій.
- Відновлення та міграція. Описуємо перенесення гаманця на новий пристрій, зміну пароля й коректний відкат до попереднього стану, якщо оновлення перервалося. Перевіряємо, що раніше створені адреси залишаються доступними.
- Перевірка на сценаріях збою. Прогоняємо втрату пристрою, обрив зв’язку на середині транзакції, пошкоджене сховище й повторне встановлення застосунку. У кожного сценарію є очікуваний результат і зрозуміла поведінка інтерфейсу.
- Передача документації та навчання. Віддаємо схему ключів, політики підпису, інструкції з відновлення та розбір відомих обмежень. Проводимо навчання команди, щоб зміни вносилися за регламентом, а не правкою на ходу.
Артефакти передачі: схеми, політики, регламенти
Передача закінчується не передачею репозиторію. У замовника має залишитися комплект документів, за яким його інженери зможуть зібрати реліз, видати доступ новому співробітнику й відновити гаманець користувача без нас.
Технічна частина
- Схема ланцюжка ключів: як з мнемонічної фрази виводяться гілки під монети й акаунти, які шляхи вважаються основними, а які зарезервовані під службові адреси.
- Конфігурація модуля підпису: параметри виведення ключів, режим шифрування локального сховища, правила підтвердження операцій і ліміти, після яких потрібна додаткова згода.
- Політики доступу до сховища: матриця ролей, за якої підпис і вивантаження резервної копії недоступні одній людині, а дії пишуться в незмінюваний журнал.
- Інструкція з міграції: порядок перенесення наявних гаманців і повторного введення мнемонічної фрази так, щоб адреси й баланси залишилися попередніми.
Організаційна частина
- Регламент відновлення доступу: окремі сценарії для загубленого пристрою, забутого пароля й частково втраченої резервної копії — із зазначенням, хто і в який строк виконує кожен крок.
- Порядок відкликання та ротації ключів: що вважається компрометацією, хто ухвалює рішення про зміну, як виводяться з обігу старі адреси й що відбувається із незавершеними операціями.
- Чек-ліст релізу: перевірки збірки на тестовій мережі, звірка контрольної суми словника, прогін відновлення з копії, фінальні перевірки перед публікацією в магазинах застосунків.
Комплект ведеться разом із кодом: зміна схеми ключів або політик доступу вимагає правки документа в тому самому зміненні, інакше він втрачає силу.
Кейс: відновлення доступу без перевипуску застосунку
Некастодіальний HD-гаманець зберігає ключі лише на пристрої, тому втрата доступу — це не збій сервера, а сценарій відновлення: мнемонічна фраза, порядок слів, вибір схеми похідних ключів із Bitcoin Improvement Proposals.
Саме на цьому кроці в клієнта накопичувалися проблеми: логіка підпису працювала, а повернути собі гаманець користувач часто не міг.
Що було до
Частка звернень до підтримки щодо втрати доступу займала близько чверті всіх тікетів. Відновлення йшло вручну: листування, скриншоти, інженер звіряв слова й вручну перебирав варіанти схем похідних ключів, відповідаючи в середньому через кілька днів.
З першої спроби доступ повертали менш ніж половині тих, хто звернувся — решта писала повторно, а частина йшла й не поверталася.
Що стало після
Додали покроковий розбір фрази: нормалізація введення, підказки за словником і явна діагностика — яке слово не проходить перевірку й чому. Схема похідних ключів підбирається автоматично за списком відомих, і користувач одразу бачить варіант із ненульовим балансом.
Час відновлення стиснувся до кількох хвилин, частка успішних спроб з першого разу зросла до 96%, обсяг ручних операцій у підтримці впав на порядок.
Міграція пройшла без перевипуску застосунку: змінювався лише модуль відновлення, він приїжджав з черговим оновленням, а наявні гаманці продовжили працювати як раніше. Схожий сценарій розбирали в публікації — опис впровадження та замірів до і після.
Чим HD-гаманець відрізняється від гаманця з однією адресою
HD-гаманець — це не «багато гаманців в одному», а одне зерно, з якого детерміновано виводиться дерево ключів. Гаманець з однією адресою зберігає єдину пару: змінив адресу — отримав новий гаманець і нову резервну копію.
У HD-гаманці зерно кодується мнемонічною фразою, а ключі виводяться за шляхами — рахунок, монета, гілка, індекс.
Відновлення. Однієї фрази достатньо, щоб повернути все дерево, включно з адресами, які застосунок ще не показував, — і копія не зростає разом з їхньою кількістю.
В одиночного гаманця копія компактна рівно до першої нової адреси: далі її потрібно перевипускати, а попередня версія тихо перетворюється на сміття.
Приватність транзакцій. Одна адреса пов’язує всі надходження в один видимий ланцюжок: спостерігач складає обіг, контрагентів і залишок. Нова адреса на кожне надходження розриває зв’язок — історію можна зібрати лише за зовнішніми ознаками, а не за структурою гаманця.
Підтримка користувачів від цього зміщується: одна фраза закриває сценарій «загубив пристрій», але зростає ціна помилки в шляху виведення та виборі мережі — при формально правильній фразі людина бачить порожній баланс.
| Ознака | Одна адреса | HD-гаманець |
|---|---|---|
| Відновлення | за ключем, копію оновлюють у разі зміни | одна фраза повертає все дерево |
| Повторне використання адрес | одна на всі операції | нова під кожне надходження |
| Обсяг резервної копії | фіксований, застаріває у разі зміни | не зростає з кількістю адрес |
| Приватність транзакцій | надходження пов’язані в ланцюжок | зв’язки розірвані за адресами |
| Трудомісткість підтримки | прості звернення, часті втрати доступу | рідші втрати, вища ціна помилок у шляхах |
Часті технічні питання та межі застосовності
Нижче — п’ять питань, які найчастіше виникають до старту. Вони стосуються не вибору технологій, а меж відповідальності: від відповідей залежить і архітектура, і те, як застосунок поводитиметься через рік після релізу.
Приватні ключі не покидають пристрій користувача: серверна частина відповідає лише за курси та агрегацію балансів. Це обмежує частину сценаріїв, зате знімає цілий клас ризиків — витік через наш сервер.
У нас уже випущено застосунок — його потрібно переписувати з нуля?
Ні. Дивимося на схему зберігання ключів і формат похідних адрес: якщо вони сумісні зі стандартом, ядро залишається, а змінюються шари роботи з мережами та інтерфейс. Переписувати має сенс лише ядро, яке не дає доступу до похідних ключів.
Хто зберігає ключі користувача?
Лише сам користувач. Seed-фраза генерується на пристрої й лежить у захищеному сховищі, копії в нас немає — відновити доступ за користувача ми фізично не можемо. Тому резервне копіювання вбудовуємо в перший запуск, а не ховаємо в налаштування.
Що буде в разі втрати пристрою?
Відновлення йде за seed-фразою на новому пристрої: адреси виводяться заново з того самого кореня, баланси підтягуються з мережі. На нашій стороні нічого не потрібно, але цей сценарій тестується окремо — він перевіряється інакше, ніж звичайний вхід.
Як додаються нові мережі?
Через опис мережі та шлях похідного ключа: ядро не змінюється, додається конфігурація й модуль підпису транзакцій цієї мережі. Якщо в мережі інший формат адрес або підпису, обсяг робіт оцінюється окремо.
Як перевіряється коректність генерації ключів?
Звіркою з еталонними тестовими векторами: один і той самий seed має давати однакові адреси за BIP-39 і BIP-44. Плюс набір тестів на відновлення — помилка в похідній ключа призводить до незворотної втрати доступу, а не до зрозумілої помилки в логах.
Обговоримо задачу й повернемося з оцінкою та планом
Розбір починається з вашої схеми зберігання: як формується мнемонічна фраза, де живуть ключі, як підписуються транзакції та що вже покрито перевірками. Від цих деталей залежить обсяг робіт і те, які ризики переходять у вимоги до захисту.
Після звернення ви отримуєте:
- розбір поточної схеми зберігання ключів і виведення адрес — що залишаємо, що перебудовуємо під BIP-39/BIP-44;
- перелік ризиків: витік мнемонічної фрази, слабкий захист локального сховища, відсутність перевірок під час відновлення;
- варіант архітектури гаманця — гарячий і холодний контур, ізоляція ключів, робота з мережею;
- послідовність робіт і план впровадження з перевірюваним результатом на кожній ітерації;
- склад команди: розробники під мобільні платформи, інженер із криптографії, тестувальник;
- формат передачі — документація, збірки, порядок оновлень і підтримки;
- строки: діапазон із припущеннями, від яких він залежить, а не одна зручна цифра.
Чим точніше ви опишете поточну схему та обмеження, тим менше припущень залишиться в оцінці. Опишіть задачу — повернемося з оцінкою робіт, строками та планом впровадження.
