Почему мобильный 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;
- перечень рисков: утечка мнемонической фразы, слабая защита локального хранилища, отсутствие проверок при восстановлении;
- вариант архитектуры кошелька — горячий и холодный контур, изоляция ключей, работа с сетью;
- последовательность работ и план внедрения с проверяемым результатом на каждой итерации;
- состав команды: разработчики под мобильные платформы, инженер по криптографии, тестировщик;
- формат передачи — документация, сборки, порядок обновлений и поддержки;
- сроки: диапазон с допущениями, от которых он зависит, а не одна удобная цифра.
Чем точнее вы опишете текущую схему и ограничения, тем меньше допущений останется в оценке. Опишите задачу — вернёмся с оценкой работ, сроками и планом внедрения.
- Хранят резервную фразу в переписке, облачных заметках или на съёмном носителе рядом с устройством — любая утечка переписки обнуляет защиту, поэтому фразу мы предлагаем хранить только офлайн и в двух независимых местах.
- Оставляют единственную копию ключевого материала у одного человека: если он недоступен, компания теряет доступ к средствам целиком, а не временно, поэтому на этапе аудита мы фиксируем порядок разделения ответственности.
- Путают пароль для входа в приложение с паролем шифрования хранилища и ждут, что сброс первого вернёт доступ — это разные вещи, и без отдельной политики восстановления такая заявка не решается.
- Просят добавить новые сети или типы адресов после выпуска, не заложив схему вывода адресов заранее: задним числом структуру не переписать, приходится делать перенос средств у всех пользователей.
- Не ведут реестр адресов и путей их вывода: при смене подрядчика или потере части документации восстановление превращается в перебор вариантов вместо точной проверки.
- Откладывают аудит схемы ключей до момента, когда прежний исполнитель уже недоступен, — тогда сначала приходится восстанавливать логику по готовому приложению, и только потом что-то менять.
- Пытаются скрыть резервную фразу от пользователя полностью, чтобы «никто ничего не делал»: в итоге человек не может восстановить доступ сам, и каждая потеря устройства превращается в обращение в поддержку.
- Считают копию приложения на телефоне резервной копией кошелька: переустановка или потеря устройства обнуляет локальное хранилище, а ключи остаются только в резервной фразе.
- Смешивают рабочие и тестовые контуры в одном приложении, и подпись реальной операции случайно уходит в демонстрационный контур (или наоборот) — границы режимов мы разводим отдельными политиками.
- Уверены, что смена разработчика означает перевыпуск приложения и новые адреса: при корректно зафиксированной схеме ключей доступ восстанавливают без перевыпуска, и это заложено в артефакты передачи.
