Перейти к содержанию
Financial Context Wiki

Холодные кошельки: офлайн-подпись, восстановление и операционные меры контроля

Узнайте, как проектировать и проверять хранение холодного кошелька на всех этапах: генерация ключей, идентификация кошелька, резервное копирование, проверка транзакций, офлайн-подпись, мультподписи, восстановление и реагирование на происшествия.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Прямой ответ

Холодный кошелек — это система хранения, которая держит секретный материал для подписания и решающий шаг одобрения вне обычной зоны воздействия подключенного к интернету программного обеспечения. Активы остаются в блокчейне; система контролирует ключи или другие полномочия, которые могут разрешать изменения состояния. «Холодный кошелек» — это операционное обозначение, а не класс устройств, определенный протоколом, и «холодность» является свойством полного рабочего процесса, а не бренда или типа подключения.

Аппаратное устройство подписи может поддерживать холодное хранение даже при подключении по USB, если приватный ключ остается изолированным. Но процесс небезопасен, когда пользователь подписывает непроверенный адрес назначения или непрозрачный вызов контракта. И наоборот, компьютер с воздушным зазором не становится безопасным только из-за отсутствия сетевого интерфейса: скомпрометированная энтропия, установочный носитель, парсер транзакций, съемный носитель, резервная копия или дисплей могут нарушить границу. Холодное хранение снижает риск удаленного извлечения ключа, но не доказывает намерение транзакции, корректность ПО, восстановимость, конфиденциальность или финальность.

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

холодный кошелёк
0 / 5
0 проверено; 5 осталось

Завершение этой проверки не доказывает безопасность актива, транзакции или системы.

Как проектировать и проверять холодное хранение

1. Определить полномочия и модель угроз

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

2. Инициализировать доверенную энтропию и программное обеспечение

Получайте устройства и ПО через аутентифицированные каналы, проверяйте состояние инициализации и поддерживаемые выпуски и отвергайте заранее созданную мнемоническую фразу или секрет из упаковки либо от помощника. Генерируйте энтропию в контролируемой среде и фиксируйте стандарт и реализацию. BIP-39 кодирует от 128 до 256 бит энтропии в мнемоническую фразу и выводит 512-bit seed из нее и необязательной парольной фразы; стандарт не превращает придуманное пользователем предложение в безопасный кошелек.

3. Зафиксировать воспроизводимые параметры кошелька

Перед крупным пополнением зафиксируйте сеть, мастер-отпечаток, стандарт деривации и полный путь, индекс аккаунта, тип адреса или скрипта и первые проверенные адреса получения. Для политик Bitcoin сохраните дескриптор вывода, контрольную сумму, происхождение ключей, порог, число подписантов, порядок ключей и ветви сдачи. Каждый подписант независимо подтверждает свой ключ и показанную политику. Считайте xpub конфиденциальными метаданными: он выводит публичные потомки non-hardened, снижает конфиденциальность и вместе с соответствующим приватным дочерним ключом non-hardened может раскрыть родительский расширенный приватный ключ BIP-32.

4. Создать резервные копии и проверить восстановление

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

5. Сформировать и проверить полное намерение

Онлайн-координатор может получить состояние цепочки и построить неподписанный запрос, но он ненадежен. Для Bitcoin PSBT проверьте сеть, каждый ввод и сумму UTXO, выход получателя, сумму, комиссию, скорость комиссии, locktime, политику sighash и проверку того, что каждый другой выход является аутентифицированной сдачей. Для транзакции EVM проверьте chainId, nonce, to, value, предел газа, лимиты комиссии и декодированные data; для EIP-712 проверьте домен, chainId, verifyingContract, поля сообщения, nonce и срок выполнения, если применимо. EIP-712 структурирует данные и разделяет домены, но стандарт явно не обеспечивает защиту от повторной передачи сам по себе.

6. Подписать через контролируемую границу передачи

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

7. Сверить результат, обслуживать систему и подготовить миграцию

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

Рабочие примеры

Пошаговое распределение и финансирование

План опеки ограничивает онлайн-взаимодействие кошелька до 5% из 100,000 units стоимости актива: 100,000 × 5% = 5,000 units горячие и 95,000 units холодные. Холодное назначение сначала получает тест 100-unit, а оставшийся перевод составляет 95,000 - 100 = 94,900 units. После обоих переводов целевой баланс холодного кошелька составляет 100 + 94,900 = 95,000 units; небольшой тест ограничивает одну ошибку настройки, но не проверяет будущие подписи или восстановление из резервной копии.

Bitcoin PSBT сбор и изменение

PSBT тратит входы 0.80 BTC и 0.35 BTC, всего 1.15 BTC. Он перечисляет 1.00 BTC получателю и оценивает 250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC. Следовательно, аутентифицированная сдача должна быть 1.15 - 1.00 - 0.000020 = 0.149980 BTC. Если подписант не может определить этот выход сдачи из своей зафиксированной политики, ему не следует подписывать, даже если общая арифметика сходится.

Максимальный бюджет EVM по сравнению с фактической платой

Аккаунт EVM начинается с 5 ETH и одобряет перевод 1.2 ETH. Лимит 30,000 gas и максимальная комиссия 50 gwei подразумевают бюджет на комиссию 30,000 × 50 gwei = 0.001500 ETH. Если транзакция использует 21,000 gas по фактической цене 25 gwei, фактическая комиссия составит 21,000 × 25 gwei = 0.000525 ETH, оставляя 5 - 1.2 - 0.000525 = 3.799475 ETH. Подписывающий должен проверить пределы комиссии и data, а не предполагать, что будет взиматься максимальный бюджет или что интерфейс, выглядящий пустым, подтверждает обычный перевод.

Устойчивость подписанта два из трёх

Политика 2-of-3 с подписантами A, B и C имеет 3 действительных подписывающих пар: AB, AC и BC. Если один подписант недоступен, остается ровно 1 пара; если один подписант скомпрометирован, этот подписант один контролирует 0 действительную пару; если два подписанта скомпрометированы, они контролируют 1 действительную пару и могут расходовать средства. Следовательно, дизайн допускает одну потерю или одну изолированную компрометацию, но не две, и восстановление по-прежнему требует правильного дескриптора, данных деривации и порядка ключей.

Риски и ошибки при проверке

  • Неверная сеть или политика: восстановление действительного ключа с неправильной сетью, типом адреса, скриптом, аккаунтом или политикой смарт-аккаунта может дать другие либо непригодные адреса.
  • Недостаточная энтропия: предсказуемая случайность, brainwallet или скомпрометированный генератор делает ключ угадываемым даже офлайн.
  • Секрет от третьей стороны: заранее напечатанная, импортированная, сфотографированная или переданная помощником мнемоническая фраза может уже контролироваться злоумышленником.
  • Утечка резервной копии: бумага, металл, облачные копии, принтеры, камеры, доставка или наследственные документы могут раскрыть все полномочия на расходование.
  • Ошибка парольной фразы: потерянная или неверно введенная парольная фраза BIP-39 может без ошибки вывести другой кошелек.
  • Несовпадение параметров деривации: пропущенные пути, типы монет, индексы аккаунтов или соглашения кошелька могут скрыть восстанавливаемые активы.
  • Потеря конфигурации: multisig-ключи без дескриптора, порога, типа скрипта, происхождения и порядка ключей могут не восстановить пополненный кошелек.
  • Утечка публичных метаданных: xpub, дескриптор, перечень адресов или база координатора могут раскрыть балансы, связи и будущие адреса.
  • Компрометация цепочки поставок: измененные оборудование, прошивка, ПО, упаковка или каналы обновления могут подменить энтропию, адреса или подписи.
  • Подмена хостом: онлайн-координатор может заменить получателя, сумму, комиссию, сдачу, calldata, типизированное сообщение или неподписанную нагрузку.
  • Недостаточный дисплей: усечение, слепая подпись, неподдерживаемые скрипты или неполное декодирование могут скрыть существенные полномочия.
  • Атака на адрес сдачи: если устройство подписи не сверяет сдачу с политикой, транзакция Bitcoin может отправить ее злоумышленнику.
  • Ошибка комиссии или nonce: завышенные комиссии, старые EVM nonce, неверный locktime или неожиданный режим sighash могут задержать, заменить или изменить исполнение.
  • Сохраняющиеся полномочия контракта: одобрения токенов, permits, модули, делегирования и вызовы администратора могут действовать дольше видимой транзакции.
  • Атака на канал передачи: QR, USB, карты памяти, кабели и форматы парсеров могут переносить вредоносную нагрузку или выводить метаданные.
  • Коррелированный порог: совместное хранение подписантов, общие seed или зависимость от одного поставщика, оператора либо места восстановления ослабляют независимость порога.
  • Физическая атака: кража, принуждение, наблюдение, вмешательство и обнаружение секрета возможны и без сети.
  • Ущерб от среды: пожар, наводнение, коррозия, деградация носителя, недоступный сейф, смерть или недееспособность могут сделать верный секрет недоступным.
  • Ухудшение совместимости: старая прошивка, неподдерживаемые деривации или скрипты и недокументированные миграции могут помешать будущему восстановлению или подписи.
  • Неполное реагирование: проверка баланса без переноса ключей, ролей, одобрений и полномочий восстановления может оставить исходную компрометацию активной.

Распространённые заблуждения

Должен ли холодный кошелек оставаться физически отключенным навсегда?

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

Монеты хранятся внутри аппаратного устройства?

Нет. Состояние блокчейна регистрирует активы. Устройство защищает или использует полномочия, которые могут подписывать транзакции, и совместимые материалы для восстановления могут воспроизвести эти полномочия на другой реализации.

Является ли мнемоническая резервная копия менее защищённой, чем устройство для подписания?

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

Устраняет ли мультиподписная система необходимость в резервных копиях и записях конфигурации?

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

Доказывает ли успешная пробная передача, что система холодного хранения безопасна?

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

Связанные темы

Источники

Навигация

Поиск по вики...