Seed & xPUB: важные тонкости в вопросах безопасности 

Всю суть различия seed-фразы и расширенных ключей (xPUB) легко свести к тезису: seed — суперключ с правами чтения и записи, а xPUB — только записи. Но на деле это не отвечает на многие вопросы, связанные с реальной практикой защиты кошельков. Своим богатым опытом и наблюдениями в этой сфере с читателями ForkLog делится Web3-предприниматель Владимир Менаскоп. 

Введение

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

Однако мой личный опыт написания материалов для проекта Menaskop & Synergis рождается не из отвлеченной теории, а из эмпирики вопросов, заданных внутри ДАО. В этот раз встретился следующий запрос: «Можно ли технически, зная два публичных адреса (например, в MetaMask — два разных ETH-счета), определить, что они сгенерированы из одной seed-фразы? (Не зная seed, просто определить принадлежность к одному seed)». 

Короткий ответ: нет, в общем случае нельзя. Но есть нюансы. О них и будет рассказано ниже. 

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

Что почитать до погружения?

Вот три статьи на русском, которые последовательно, сверху вниз, следует изучить перед или хотя бы после прочтения данного материала:

1. «Иерархическая генерация ключей». В этой статье рассмотрены все основные абстракции, необходимые для осознания формирования seed-фразы, xPUB и кошельков из них; 
2. «Все про seed-фразу». Здесь погружение уже не столь глубокое, но зато все рассказано с прицелом на практику;
3. «О том, как забрать приватный ключ из seed-фразы». Тот случай, когда автор «делает и понимает». 

Теперь перейдем к вопросам и ответам на них. 

Загадки в темноте

Цель этой статьи в том, чтобы найти множество точек, связанных с одной: seed-фразой. Хотя каждая точка не обязательно связана с любой другой, за счет связи с главной можно выискать нечто важное, что обычно ускользает от внимания или обсуждается в рамках узкоспециализированных вопросов-ответов. Итак, вопросы. 

Изначальные

Несколько тезисов из дискуссии, обозначенной выше:

Какие еще трудности возникают?

Если хотите довести какую-либо дискуссию до максимума или даже до абсурда, то есть два пути: Reddit, если хотите поговорить обо всем сразу, и Stack Exchange, если желаете затронуть более технические аспекты. И вот что мне удалось отыскать в бездне историй, напрямую связанных с seed-фразой :

1. Поскольку массовое использование мнемонических фраз настало в 2013 году, логично предположить, что с того момента и подходы менялись не раз. Порой не так просто восстановить что-то из старого инструментария, но это необходимо. Пример: «Слова взяты из списка мнемонических слов примерно 2013 года, определенно не из BIP39. Всего есть 16 слов». Подобных историй десятки и даже сотни;
2. Следующий распространенный вопрос: «У меня есть: 1) моя начальная фраза из 12 слов и 2) адрес учетной записи (0x…), связанный с этой начальной фразой. Однако у меня нет закрытого ключа этого конкретного счета. Есть ли способ получить закрытый ключ этого конкретного счета из начальной фразы?». Ответ дан в статье №3 из раздела «Что почитать для погружения?»; 
3. Или вот такой интересный вопрос: «Недостатком схемы HD с несколькими подписями по сравнению со схемой с общим секретом Шамира является необходимость резервного копирования ключей xPUB. Для xPUB нет кодировки, подобной BIP39… Существует ли схема с несколькими подписями M-of-N (M < N), которой требуется только M закрытых ключей, что значительно упрощает резервное копирование (и восстановление)?». Ответ дан по ссылке на сам вопрос, но нам интересна именно его постановка. К ней вернемся в разделе о типах кошельков.

Как можно заметить, все это вопросы разных лет, людей и сообществ, поэтому можно говорить об их универсальности, от которой и будем отталкиваться. 

Понятия и их содержание

Начнем с базы:

• Деривация, а точнее путь деривации — фрагмент данных, который указывает кошельку Hierarchical Deterministic (HD), как вывести определенный ключ в дереве ключей. 
• Deterministic wallet — кошелек, в котором все используемые личные ключи были порождены из одного общего для всех ключей секрета. Базово все это приводит нас к SEED. Но прежде — еще один термин: BIP. Что это?  
• BIP — Bitcoin Improvement Proposal — предложение по улучшению кода биткоина, оформленное в соответствии с официальными правилами. Важно, что идею BIP может выдвинуть любой пользователь, однако для добавления в код первой криптовалюты и окончательной активации оно должно получить одобрение разработчиков и майнеров. Для нас важны следующие BIPs:
  • BIP32 (см. ниже примеры);
  • BIP39: ссылка №01, ссылка №02, ссылка №03 и ссылка №04. 
• Еще один важный термин HMAC (иногда расшифровывается как hash-based message authentication code, код аутентификации (проверки подлинности) сообщений, использующий хеш-функции, или как keyed-hash message authentication code, код аутентификации сообщений, использующий хеш-функции с ключом). Это один из механизмов проверки целостности информации, позволяющий гарантировать то, что данные, передаваемые или хранящиеся в ненадежной среде, не были изменены посторонними лицами.
• Сериализация (Serialization) — процесс, который переводит объект в последовательность байтов, по которой затем его можно полностью восстановить. 
• И, наконец, расширенный открытый ключ — специальный ключ, который эффективно представляет группу открытых ключей и, соответственно, адресов. Каждый, кто имеет к нему доступ, может видеть все адреса, полученные на его основе.  

Попробуем визуализировать базовую схему. Выглядеть она может следующим образом:

• Master seed -> master key
• Private parent key — private child key
• Private parent key -> public child key
• Public parent key -> public child key
• Public parent key X private child key

И уже теперь зададимся вопросом: «Какова же связь между seed, xPUB и private key?». 

xPUB, yPUB, zPUB и т. д.

Вот что можно узнать о них из этого исследования:

• xPUB. Это название расширенного открытого ключа. xPUB используется на старых кошельках, адреса которых начинаются с 1. xPUB создается на биткоин-стандарте BIP32 и обеспечивает доступ к кошельку только для чтения. xPUB позволяет просматривать все транзакции, адреса и балансы конкретного кошелька, но не позволяет тратить баланс. Чтобы потратить баланс, нужен закрытый ключ.
• yPUB. То же самое, что и xPUB, но символ «y» означает, что расширенный открытый ключ принадлежит кошельку со стандартом биткоина BIP-49, в котором подробно описана схема адресации, совместимая с более старыми версиями, чем SegWit. Ключ yPUB имеет адрес типа P2SH-P2WPKH.
• zPUB.  Имеет тот же принцип, что и yPUB, но схема адресации не является обратно совместимой. Она соответствует типу адреса P2WPKH, поэтому zPUB предназначен для кошельков, изначально совместимых с SegWit.

На данный момент существует целый зоопарк различных расширенных открытых ключей: xPUB, yPUB, zPUB, tPUB, uPUB, vPUB. Все они являются расширенными открытыми ключами, как и их «старшие братья» Ypub, Zpub, Upub и Vpub. 

Но нас интересует не nPUB-подход, а его соотношение с seed? Да, именно. Поэтому сделаем следующий шаг. 

Seed vs. xPUB

Прелесть xPUB ясна: пользователь позволяет стороннему сервису вместо себя генерировать такие адреса, которые будут известны сервису, но личные ключи будут только у пользователя.

Но есть ли у этого подхода недостатки? И есть ли они вообще, когда из «одного порождается многое»? Давайте попробуем рассмотреть их через атаки.

Брутфорс-тренировки

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

1. bip32jp.github.io/english
2. iancoleman.io/bip39
3. github.com/bitcoin/bips/blob/master/bip-0032.mediawiki 

Но сразу возникает резонный вопрос: «Сколько времени на это может уйти?». То есть на прямой и тупой перебор. Вот два примера:

1. Первый — с ForkLog: «Биткоин-энтузиаст подобрал seed-фразу из известных слов за полчаса»; 
2. Второй — с Habr: в этом материале расписаны более точные параметры перебора в том или ином случае. 

Вывод прост: если знаем все или почти все слова и их немного (скажем, 12), а словарь известен, как и язык, на котором он составлен, то на взлом времени уйдет не просто немного, но катастрофически мало. Если же слова неизвестны, как и их порядок, то и вечности не хватит для подбора/перебора. 

К тому же бывают случаи, когда изначально формирование кошельков пошло не по правилам: достаточно вспомнить о Profanity. 

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

Атака отправления адреса

Сразу отмечу, что изначально подобные атаки проводились на vanity-адреса, но потом расплылись по миру и других форматов. 

Этот тип атаки я вспомнил сразу, как только был задан первый вопрос, из которого родилась статья. 

Вот что по этому поводу написали в Ledger: «Остерегайтесь скамеров, которые рассылают небольшое количество монет или NFT, чтобы „запачкать“ историю ваших транзакций в Ledger Live. Они могут маскироваться под полученные транзакции, NFT или даже правдоподобные отправленные транзакции или уплату комиссии сети. Всегда дважды проверяйте детали транзакции на устройстве Ledger, чтобы по ошибке не отправить средства на подставной адрес мошенника. Будьте бдительны, адреса мошенников могут быть очень похожи на ваши. Никогда не копируйте и не используйте адреса из истории транзакций. „Отравленный“ счет можно использовать в обычном режиме. Отравление счета не является его взломом».

Если интересуетесь проблемой, рекомендую изучить это обсуждение. В любом случае стоит запомнить одно: любая бесплатная «пыль», которая прилетела к вам на кошелек, изначально токсична. Но не стоит делать поспешных выводов: заражение адреса — не панацея, а один из способов форензики децентрализованных и распределенных систем.

Другие атаки

Они вытекают как из архитектуры устройств и ПО, так и из ошибок пользователя и плохо скроенных сервисов. Поскольку разборы на ForkLog уже были, отсылаю к одному из них. И задам наконец самый важный вопрос. 

Сопоставить кошельки к seed-фразе: можно или нет?

Во-первых, давайте определимся: зачем это нужно? И, во-вторых, кому. 

Ответы таковы:

1. Хакерам, чтобы взломать неудачливых пользователей.
2. Простым пользователям, чтобы понять механизм работы какого-то dapp. 

Начнем со второго случая, поскольку благодаря MetaMask он стал весьма массовым. 

ММ

В умелых руках MetaMask — довольно мощный и гибкий инструмент. Тем, кто хочет глубже ознакомиться с его возможностями, советую изучить этот и этот материалы.

Но вопросов к MetaMask от этого не меньше. Возьмем официальную документацию: «MetaMask попытается добавить ваши дополнительные счета, где это возможно (предполагается, что они не были импортированы), проверяя ваши предыдущие счета в порядке возрастания (т. е. счет 2, затем счет 3 и т. д.). Счета автоматически добавляются повторно, если они имеют ненулевой баланс ETH. Однако этот процесс заканчивается, когда MetaMask встречает счет с 0 ETH — поэтому первый счет с 0 ETH (и все последующие) не будут добавлены».

Из-за этого подхода не раз возникали трудности. Вот живой пример: «Слетел MetaMask в браузере по непонятным причинам, пришлось восстановить. Сама проблема в том, что к нему было привязано два кошелька, второй был добавлен там же через „Create account“. При восстановлении первый появился, а второго нет. Получается, он просто пропал?».

Или вот: «Не могла зайти в аккаунт MetaMask и воспользовалась восстановлением аккаунта через seed-фразу и пароль. У меня открылся кошелек, но там другой счет! Я не сохраняла закрытый ключ к счету (к сожалению, не знала о такой функции ранее). В техподдержку MetaMask написала, но ответа пока нет. На просторах интернета подобной проблемы не встречала. У меня нет скрытых счетов в кошельке, потому что у меня был один кошелек и один счет. Seed-фраза была точно правильной, потому что когда я ввела ее и пароль через восстановление, у меня открылся аккаунт кошелька, просто с совершенно другим счетом. Эту трагедию я обнаружила вчера и новым счетом не пользовалась». 

Поэтому многие и пытаются сопоставить адреса любым способом. Проблемы здесь две:

1. xPUB в описанном выше ракурсе — прерогатива UTXO-систем; 
2. сопоставить же каким-то подобием взлома соотносимые кошельки можно лишь в случае, если ими пользуетесь, а не пытаетесь восстановить. 

И здесь порочный круг замыкается: то, что работает против вас, не работает на вас. Парадоксально? Да, но это факт. 

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

1. Аппаратные кошельки можете использовать для первичного холодного хранения;
2. Импортированные — для тестов и связи сервисов; 
3. Первичные (из seed-фразы) — для тестов и простых операций. 

Но все же связка с Trezor & Ledger и/или их аналогами требуют отдельного пояснения. 

Seed и железо

Что есть на рынке? 

Прежде всего, если хотите изучить рынок «железных» кошельков, ознакомьтесь с таблицей, которую составил постоянный гость ForkLog-подкастов Алекс Петров. В ходе эволюции в ней могут меняться конкретные устройства, но критерии оценки важны сами по себе: 

Актуальные данные можно найти на BitcoinTalk. Но теперь перед нами встает еще один важный вопрос.

Что известно про взломы?

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

Поэтому не важно, хотите добыть золото из олова (что возможно) или взломать сеть биткоина, вы должны оценить все через простую формулу: P(hack) > P(system). 

Отсюда, когда говорят о взломе seed-фразы или ее «выуживании» из аппаратных решений, забывают упомянуть, сколько сил/энергии/денег будет затрачено на это? Мы же этой ошибки совершать не должны. 

Зная вышесказанное, попробуем оценить два последних случая и их концептуальное различие:

1. Физический взлом Trezor T: впрочем, на старые модели этот взлом тоже распространялся, т.к. известен давно, а решение кроется в уместной защите через passphrase.  
2. Компрометация seed-фразы в Ledger: в этой истории, скажу сразу, прекрасно все, особенно — объяснения CTO. Здесь об уместности говорить не приходится, т. к. это вопрос идеологии, а не сугубо архитектуры. 

Разница между потенциальной компрометацией seed-фразы в Ledger и фактическим вылавливанием таковой в Trezor состоит в том, что в последнем случае мы принимаем это как неизбежный баг (или фичу?) разработанной системы, вроде того, как принимаем атаку 51 в PoW. А вот в первом фактически нарушается социальный консенсус, который предполагает, что никто, кроме пользователя, не может влиять напрямую на его активы (не на их стоимость, но на факт владения и распоряжения). 

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

Что еще нужно знать владельцам аппаратных кошельков?

Что идеальных систем не бывает. Вот, например, описание аспектов работы TROPIC01 и связанных элементов от все того же Алекса Петрова:

• На сегодня Satoshi Lab продвинулись в обсуждения секьюрности железа, но «это, по сути, исследовательская работа, которую поддерживает [ряд участников крипторынка], но это далеко не финальный продукт».
• Создание действительно безопасного чипа — большая работа, требующая хорошего практического опыта, в том числе и в том, как создавать такие сложные вещи и как их защищать.
• Наличие таких вещей, как RISC-V — не панацея.
• Проблема нынешних решений от Trezor — в STM32F который дешев, но небезопасен. 

Поэтому повторюсь: идеальных решений нет и быть не может. Но, все же кое-что вы сделать можете. 

Правила безопасности

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

К первичным следует отнести:

1. Хранение seed на двух-трех альтернативных источниках: как правило, бумажная копия или копия в металле, децентрализованное хранение среди доверенных людей и, например, зашифрованная флешка в сейфе;
2. Применение правил цифровой гигиены, даже если они кажутся вам избыточными. Посвященная им статья в двух частях (первая, вторая) опубликована в ForkLog Community HUB; 
3. Полное погружение в тезис «если нечто написано опытом и кровью, не стоит тратить силы на перепроверку». Seed-фразу не нужно никогда и никому передавать, публичный общий ключ — тоже. 

Что же касается соотношения Seed & xPUB, надеюсь, оно стало яснее.