BIP 39

Алиса создаёт кошелёк, использующий BIP39, и по его инструкции надёжно сохраняет слова восстановления. Спустя некоторое время телефон ломается. Биткоины не исчезли из сети: она потеряла устройство, на котором хранились ключи для подписания платежей. На надёжном устройстве взамен старого она может воспользоваться функцией восстановления совместимого кошелька. Те же слова в том же порядке и та же passphrase, если она использовалась, дадут тот же seed. Следующие процедуры заново создадут из него нужные приватные ключи, а кошелёк найдёт платежи в сети Bitcoin. Это не вход в аккаунт, пароль от которого может сбросить служба поддержки. Если Алиса использовала passphrase, она тоже нужна; PIN старого телефона её не заменит. Нулевой баланс после восстановления не обязательно означает потерю монет: кроме слов и passphrase, нужно проверить выбранный счёт и настройки восстановления. Именно поэтому полезно проверить весь процесс до хранения значительной суммы. [1] [5] [13] [14]

Слова легче переписать и проверить, чем длинную запись компьютерных данных. Marek Palatinus, Pavol Rusnak, Aaron Voisine и Sean Bowe предложили способ представить созданную компьютером случайность в форме, удобной для переписывания от руки. Предложение датировано 10 сентября 2013 года и имеет в спецификации статус Deployed. Слова должны формироваться из качественных случайных входных данных; не следует придумывать их на основе любимой фразы. Так получился бы Brainwallet с предсказуемым секретом, выбранным человеком. Узлы Bitcoin не проверяют BIP39: они проверяют транзакции и блоки, а не способ, которым кошелёк создал свои ключи. [1]

Хорошая запись поможет лишь тогда, когда по ней можно восстановить кошелёк. Перед хранением значительных средств проверьте на доверенном устройстве процедуру восстановления, рекомендованную производителем. Помимо точного порядка слов сохраните необходимую passphrase, сведения о кошельке и, если нужно, настройки деривации или подписания. В обычном кошельке, требующем одной подписи, владелец полной резервной копии с необходимой passphrase может получить ключи без исходного устройства; при Multisig нужно выполнить дополнительные требования к ключам и правилам подписания. Фотографии, облачная копия, принтер или история буфера обмена могут раскрыть секреты другим людям и сервисам. Бумага и металл имеют разные физические ограничения; ни один материал сам по себе не предотвращает кражу. [9] [13] [14]

Ради совместимости BIP39 настоятельно рекомендует английский список слов: многие кошельки не поддерживают другие списки. Перевод резервной копии не сохраняет исходный кошелёк, поскольку при получении seed используется сам текст фразы. Учитывайте и другие системы. Electrum использует для собственных резервных копий отдельную процедуру версионирования; похожий вид слов не делает их автоматически BIP39. SLIP39 — другой формат со своим списком из 1 024 слов и правилами, определяющими, сколько долей нужно для восстановления. Это не простое разрезание резервной копии BIP39 на части. Если разложить 24 слова по нескольким конвертам, это не будет Shamir Secret Sharing и может ухудшить как защиту, так и возможность восстановления. Всегда нужно знать настоящий формат резервной копии. [1] [11] [12]

В начале находится энтропия, то есть случайные данные длиной ENT = 128, 160, 192, 224 или 256 бит. К ним добавляется контрольная сумма: первые CS = ENT/32 бит результата SHA-256 от исходных данных. Всё вместе делится на группы по 11 бит, каждая из которых определяет одно слово. Поэтому соотношение MS = (ENT+CS)/11 даёт ровно 12, 15, 18, 21 или 24 слова. Двенадцать слов представляют 128 бит случайности и 4 контрольных бита; следовательно, не все 132 бита являются независимым секретом. Для 24 слов это 256+8 бит. Доверие к резервной копии начинается с генератора случайности, а не с того, насколько необычно выглядят слова. [1]

Каждая 11-битная группа выбирает один элемент из упорядоченного списка из 2 048 слов. Первое слово, таким образом, не является первым приватным ключом: все слова вместе записывают исходные данные и их контрольную сумму. В английском списке для различения слов достаточно первых четырёх букв. Однако это не общее правило для любого языка и не указание произвольно сокращать резервную копию при восстановлении. Изменение порядка, замена слова синонимом или перевод меняют входные данные. Иногда получается неверная контрольная сумма, иногда — другая корректная резервная копия; поэтому написание и порядок слов нужно сохранять точно. [1] [2]

Компьютер должен знать, какие именно символы он получил. BIP39 предписывает нормализацию Unicode NFKD и последующее кодирование UTF-8 как для фразы восстановления, так и для passphrase. NFKD приводит к общему виду некоторые разные способы записи символов, например разлагает отдельные буквы с диакритическими знаками. Поэтому две разные записи могут после нормализации дать одинаковый результат; одно лишь визуальное сходство этого не гарантирует. Порядок слов, пробелы и символы passphrase по-прежнему имеют значение. Другой способ нормализации при восстановлении может привести к получению другого seed. Эталонная реализация и открытые тестовые векторы помогают проверить, соблюдает ли программа предписанную процедуру. [1] [3] [4]

PBKDF2 получает два отдельных входа. Вход password состоит из настоящих слов для восстановления. Второй вход называется salt и содержит дополнительные данные для криптографического вычисления. Здесь это буквальный текст «mnemonic», к которому без разделителя добавляется passphrase. Сами слова для восстановления сюда повторно не вставляются. Оба входа нормализуются с помощью NFKD и кодируются в UTF-8. BIP39 задаёт HMAC-SHA512, 2 048 итераций и результат длиной 512 бит, то есть 64 байта. Без passphrase значение salt остаётся «mnemonic»; пустой является только passphrase. Вычисление не расшифровывает слова и не создаёт новой независимой случайности. Поэтому после утечки слов сами итерации не защитят passphrase, которую легко угадать. [1] [10]

BIP39 заканчивается seed длиной 64 байта. Другой стандарт, BIP32, обычно с помощью HMAC-SHA512 с фиксированным ключом «Bitcoin seed» получает из него главный приватный ключ и 32-байтовый chain code. Chain code — это дополнительные данные, которые вместе с ключом используются для получения следующих ключей. Эти два элемента становятся основой дерева ключей. Правила, такие как BIP44, BIP49, BIP84 и BIP86, задают разные пути деривации и типы скриптов. Поэтому при восстановлении можно ввести правильные слова и passphrase, но увидеть нулевой баланс, если программа ищет другой счёт, другую ветвь или другой тип адресов. Важен и gap limit — количество неиспользованных адресов подряд, которое программа допускает при поиске. Название исходного кошелька, сведения о счетах, пути деривации или Output Descriptor могут дополнить информацию, которой нет в самих словах. [5] [6] [7] [8] [9] [14]

Passphrase — дополнительный секретный вход для получения seed. Это не PIN устройства, а BIP39 не может сообщить, что вы ввели неправильную passphrase: он вычислит результат и для другого значения. Опечатка, которая меняет нормализованный вход, обычно приводит к другому кошельку, где вы не увидите своих средств. Напротив, разные записи с одинаковым результатом NFKD дают один и тот же seed. Тот, кто получил слова для восстановления и сведения, позволяющие узнать нужный кошелёк, может проверять возможные значения passphrase офлайн. Если вы используете passphrase, ей необходимы достаточная стойкость, надёжный способ ввода и собственная надёжная резервная копия. Раздельное хранение должно снижать риск одновременной кражи обоих секретов, а не превращать passphrase в тайну, которая исчезнет вместе с вами. [1] [13]

Контрольная сумма помогает обнаруживать опечатки, но не доказывает, кому принадлежит резервная копия и была ли она создана безопасно. Для 12 слов она содержит 4 бита, а для 24 слов — 8 бит. Поэтому равномерно случайная последовательность слов из соответствующего списка проходит проверку с вероятностью 1/16 или 1/256 соответственно. Многие ошибки будут обнаружены, но не все; сама контрольная сумма их также не исправляет. Злоумышленник может создать другую резервную копию с правильной контрольной суммой. Спецификация требует предупреждения при несовпадении и отделяет проверку слов от самого получения seed. Поэтому проблему неверной контрольной суммы следует разбирать с учётом исходного кошелька и его формата, а не вводить настоящую резервную копию в интернет-сервис для проверки. [1]