Аппаратные кошельки: как инженеры защищают секрет

Представьте, что вы подключили устройство для подписи транзакции к заражённому компьютеру. Программа на компьютере может подменить адрес получателя, но устройство показывает отдельный экран и просит подтвердить операцию кнопкой. В этом и состоит обещание аппаратного кошелька: секретный ключ не покидает защищённую среду, а подпись создаётся внутри устройства. Но насколько это защищает? Ответ зависит от угрозы, которую устройство пытается остановить: вредоносной программы, физического доступа, подмены прошивки, ошибки пользователя или компрометации резервной копии.

Содержание

1. Что именно изолирует устройство
2. Экран и кнопка подтверждения
3. Прошивка и обновление
4. Цепочка поставки
5. Почему резервная копия так важна
6. Что остаётся человеку

Что именно изолирует устройство

В обычном программном кошельке ключи хранятся на компьютере или смартфоне. Это удобно, но любой вредоносный код с нужными правами может попытаться прочитать секрет, изменить данные или перехватить ввод. Аппаратный signer — отдельное устройство, которое обычно хранит seed и выполняет криптографические операции самостоятельно. Компьютер передаёт ему запрос на подпись, а устройство возвращает подпись, не отдавая исходный закрытый ключ.

В основе многих кошельков лежит иерархическое получение ключей. Из одной начальной случайной величины, seed, по определённым правилам выводятся пары ключей для адресов и счетов. BIP-32 описывает дерево ключей, а BIP-39 — мнемоническую фразу для представления энтропии и получения seed. Пользователь может видеть адрес или публичный ключ, не раскрывая соответствующий закрытый ключ. Это разделение позволяет устройству подписывать операции, а компьютеру готовить транзакции и показывать историю.

Слово «изолирует» не означает, что устройство никогда не общается с внешним миром. Оно подключается по USB, Bluetooth или через другой канал, принимает запросы и передаёт данные. Цель архитектуры — сделать так, чтобы взаимодействие не позволяло хосту просто извлечь закрытый ключ или подписать что угодно незаметно. Граница защиты зависит от того, что именно проверяет firmware, какие части секретов доступны приложению устройства, как устроен экран и какие действия требуют физического подтверждения.

Производители используют разные сочетания микроконтроллеров, защищённых элементов (secure elements), памяти и программных слоёв. Защищённый элемент может хранить ключ или помогать ограничивать попытки PIN-кода и сопротивляться физическим атакам. В модели Ledger Nano X, описанной в документе Security Target французского агентства ANSSI, выделены отдельные компоненты Secure Element и программное обеспечение устройства. Это пример одной модели и конкретной сертификационной документации, а не универсальное описание всех аппаратных кошельков.

Любая такая конструкция меняет распределение доверия, но не убирает его полностью. Пользователь доверяет генерации случайности, реализации криптографии, прошивке, экрану, цепочке поставки и процедуре восстановления. Открытый исходный код может облегчить независимый анализ программной части, но не делает автоматически проверенными чип, производственный процесс, сборку и каждую версию приложения. Закрытые компоненты не доказывают небезопасность, а открытые не исключают уязвимостей.

Экран и кнопка подтверждения

Защищённый экран нужен не для того, чтобы просто показать, что устройство включено. Он должен помочь человеку сверить смысл операции с тем, что собирается подписать ключ. Если компьютер заражён, он может подменить адрес в буфере обмена или сформировать другой запрос. Устройство, которое независимо отображает получателя и сумму, создаёт второй канал проверки: пользователь сравнивает данные не только на экране хоста.

Но этот барьер работает лишь тогда, когда человек действительно сверяет поля и способен их понять. Адрес длинный и неудобен для ручной проверки; интерфейс может показывать его частично. В сложных контрактах экран иногда сообщает, что будет подписана непрозрачная последовательность данных, а не понятная операция. Тогда физическое нажатие подтверждает криптографический запрос, но не осознанное понимание последствий.

Исследование EthClipper 2021 года разбирало подмену адреса в буфере обмена и обход привычной проверки адреса. Вывод шире одной атаки: длинная строка может быть трудной для надёжной визуальной сверки, а привычка копировать адрес без независимого подтверждения превращает дополнительный экран в формальность. Для контрактов и токенов проблема усложняется: пользователь может видеть технические данные, не понимая, меняют ли они владельца, одобряют ли трату токенов или выполняют другую функцию.

Именно поэтому термин clear signing стал отдельным направлением: устройство и приложение стараются показать важные поля операции в читаемой форме. Это требует поддержки конкретной сети и контракта; неизвестный тип вызова всё равно может оказаться нечитаемым. Ни экран, ни кнопка не могут определить, является ли сайт мошенническим или разумно ли отправлять средства. Они подтверждают, что пользователь разрешил операцию, а не то, что операция выгодна или безопасна.

Прошивка и обновление

Устройство выполняет программу, а значит, безопасность зависит от прошивки. Модель угроз должна отвечать на несколько вопросов: кто может изменить код, как устройство проверяет его подлинность при запуске, как устанавливаются обновления и что происходит, если проверка не проходит? NIST SP 800-193, опубликованный в 2018 году, описывает принципы устойчивости платформенной прошивки: защищать её от несанкционированных изменений, обнаруживать такие изменения и безопасно восстанавливаться.

Подписанное обновление помогает доказать, что файл одобрен владельцем ключа подписи производителя. Bootloader или аналогичный слой может отказаться запускать неподписанную версию. Но подпись отвечает на ограниченный вопрос: «прошивка подписана допустимым ключом?» Она не доказывает, что в коде нет ошибок, что сервер распространения не был скомпрометирован, что подпись не выдана ошибочно или что обновление подходит конкретной модели. Для этого нужны процесс разработки, аудит, контроль ключей, реагирование на уязвимости и возможность выпускать исправления.

Есть и вопрос доступности: если корневой ключ подписи производителя утерян или скомпрометирован, выпуск обновления может стать сложным, а новый сертификат потребует отдельного механизма доверия. Безопасная система продумывает не только нормальный запуск, но и аварийное восстановление. Это означает подписанные и проверяемые образы, документированный процесс отзыва скомпрометированного ключа, понятные сообщения об ошибках и способ вернуться к рабочему состоянию, не раскрывая seed.

Обновления несут двойную роль. Отказ от установки патчей оставляет известные слабости; установка из случайного источника может поставить вредоносную программу. Пользователь должен сверять версию и канал обновления с официальной документацией именно своей модели. Если устройство показывает неожиданное предупреждение о прошивке или подлинности, игнорировать его ради продолжения операции рискованно. В то же время одно только предупреждение не говорит, как именно устроена проверка, поэтому важна точная документация производителя.

Компрометация одной части цепочки может менять поведение устройства. Корень доверия может быть встроен в аппаратный компонент или зафиксирован при производстве. Загрузчик проверяет следующий слой, а прошивка — приложения и операции. Чем больше функций вынесено в разные компоненты, тем важнее понимать границы между ними. Сложная схема способна разделить последствия отказа, но каждый дополнительный интерфейс и канал обновления также требует проверки.

Цепочка поставки

Даже хорошо спроектированное устройство можно подменить до того, как оно попадёт к владельцу. Риск может появиться в производстве, упаковке, доставке, возврате товара или у посредника. Защитные наклейки и проверки подлинности помогают выявлять некоторые виды вмешательства, но не являются абсолютным доказательством: упаковку можно воспроизвести, а проверочная программа может зависеть от производителя и его серверов.

Для снижения риска важно понимать происхождение устройства и способ первого запуска. Поддельная инструкция может попросить ввести seed на сайте; это сразу обходит аппаратную защиту, потому что секрет вводится в среду, которую устройство не контролирует. Устройство, пришедшее с заранее созданной фразой или требующее отправить резервную копию «в поддержку», не следует считать безопасным только из-за корпуса и логотипа.

Проверка подлинности тоже имеет границы. Сертификат или приложение могут подтвердить, что устройство отвечает ожидаемым криптографическим ключом, но не обязательно доказывают, что на всём пути к покупателю не было вмешательства. В свою очередь, пломба может показать физическое вскрытие упаковки, но не подтверждает, что внутри нет дефекта разработки. Поэтому инженерная модель часто комбинирует защиту компонентов, аутентификацию прошивки, программную проверку и инструкции для пользователя: один признак не должен нести на себе весь вывод о безопасности.

Безопасность цепочки поставки — общая задача изготовителя, продавца и пользователя. Производитель контролирует производство, подписи и каналы распространения; продавец отвечает за происхождение товара; покупатель может проверить официальный канал и подлинность по документации. Ни один сигнал отдельно — запечатанная коробка, голограмма, приложение проверки — не покрывает все возможные сценарии. Если сомнение касается источника или целостности, рискованно создавать основной кошелёк на этом устройстве.

Почему резервная копия так важна

Аппаратное устройство можно потерять, сломать или сбросить, поэтому средства восстановления остаются частью модели безопасности. BIP-39 кодирует случайную энтропию мнемонической фразой и применяет процедуру получения seed. Эта фраза часто даёт возможность восстановить все производные ключи, а значит, её защита может быть важнее защиты самого корпуса. Тот, кто получил фразу, в большинстве сценариев может восстановить кошелёк на другом устройстве.

Резервная копия создаёт вторую поверхность риска: её могут сфотографировать, украсть, найти при ремонте или получить через фишинговый сайт. Записывать seed на подключённом к интернету устройстве, отправлять его в облачную заметку или передавать сотруднику поддержки опасно. Но чрезмерно сложная схема хранения тоже может привести к потере: если владелец забывает, где лежат копии, или не может прочитать повреждённую запись, доступ исчезает вместе с единственным рабочим устройством.

Passphrase в совместимых системах меняет выводимое дерево ключей и создаёт дополнительные требования к памяти и наследованию. Опечатка может открыть другой, формально действительный кошелёк, в котором ожидаемых средств не будет. Это не просто «ещё один пароль», который можно сбросить через поддержку. Нельзя добавлять такую защиту, не понимая совместимость устройства, резервирование и процедуру восстановления.

Ключевое решение — спроектировать восстановление до того, как оно потребуется. Нужно знать, что именно записывает резервная копия, какие устройства и программные реализации смогут её импортировать, кто имеет к ней доступ и как близкие смогут действовать при утрате владельца. Это редакционный принцип, а не конкретная схема хранения: допустимый выбор зависит от суммы, угроз и семейных обстоятельств.

Что остаётся человеку

Аппаратный кошелёк не защищает от всех способов потерять средства. Он может затруднить удалённое извлечение ключа с заражённого компьютера, но не помешает владельцу самому подтвердить вредоносную операцию, раскрыть seed фишинговому сайту или отправить актив на ошибочный адрес. Он не гарантирует правильность смарт-контракта, честность сайта, сохранность резервной копии и возможность отменить транзакцию после подтверждения.

Поэтому модель угроз должна начинаться с вопроса «от кого и от чего защищаемся?». Для сетевого злоумышленника важна изоляция ключа и независимая проверка операции. Для физического похитителя — защита PIN, ограничения попыток и стойкость аппаратных компонентов. Для подмены до покупки — цепочка поставки и проверка подлинности. Для поломки — надёжное восстановление. Для ошибки пользователя — читаемый экран, понятная процедура и осторожное обращение с секретом.

Производитель может снизить вероятность ряда атак, но не обещать абсолютную безопасность. NIST в рекомендациях по управлению ключами рассматривает секреты вместе с жизненным циклом: создание, хранение, использование, резервирование и уничтожение. Для криптокошелька эта перспектива полезна: ключ защищён не только в момент подписи, но и пока фраза существует в резерве, устройство обновляется и владелец принимает решение.

Инженерная ценность аппаратного кошелька — в локализации доверия. Компьютеру не обязательно знать закрытый ключ; отдельный экран даёт шанс проверить детали; защищённый элемент может ограничить часть физических атак; подписи прошивки помогают выявлять несанкционированные изменения. Но каждый слой отвечает на ограниченный набор угроз и имеет собственные допущения. Устройство безопасно настолько, насколько его реальные границы соответствуют угрозам владельца и насколько человек понимает, что именно он подтверждает и как будет восстанавливать доступ.

Источники и дальнейшее чтение

1. BIP-39, Mnemonic code for generating deterministic keys, назначен 10 сентября 2013 года; спецификация восстановления seed.
2. BIP-32, Hierarchical Deterministic Wallets, 2012; спецификация дерева ключей.
3. NIST SP 800-193, Platform Firmware Resiliency Guidelines, финальная редакция 4 мая 2018 года.
4. NIST SP 800-57 Part 1 Revision 5, Recommendation for Key Management, опубликована в мае 2020 года.
5. ANSSI, Ledger Nano X Security Target, документ сертификационной оценки модели Nano X, 2023.
6. Trezor, объявление запуска Safe 3 и Keep Metal, 12 октября 2023 года; заявление производителя о своих продуктах.
7. EthClipper: A Clipboard Meddling Attack on Hardware Wallets with Address Verification Evasion, arXiv, 2021.