Неочевидная опасность холодных кошельков

Что за строка выше? Не знаете? И я не знаю. А там — отправка одного эфира на сторонний адрес. Представьте, как неприятно было бы узнать о том, что подписал такое постфактум.

А владельцам базовых Ledger Nano S, Trezor Model T, SafePal S1 и ещё кучи кошельков и представлять не нужно. Для них подобное — реальность.

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

Почему так?

Когда мы хотим осуществить какое-то web3-взаимодействие, мы формируем тело транзакции вида

и формируем hash-to-sign

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

Чтобы мы знали, горячие (то есть подключённые к интернету) кошельки научились симулировать транзакции. Они могут это делать, т.к.:

Что из этого может делать холодный кошелёк? Очевидно, ничего — иначе какой из него, собственно, холодный кошелёк.

Таким образом, source of truth для холодных кошельков всегда выступает их «горячая» часть: приложение или расширение, которое по своей специфике всегда может быть скомпрометировано.

То есть злоумышленнику достаточно подменить строку, передаваемую на ваш холодный кошелёк, не трогая передаваемую метадату — и вуаля. Вы думаете, что подписываете одну транзакцию, а по факту — совсем другую.

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

Типичная стратегия — зашивать знания о популярных токенах и их параметрах в прошивку, а затем бесконечно её обновлять.

Это ведёт к:

Также появляются более сложные решения:

Но достаточно пары минут, чтобы представить массу вариантов, как это может быть скомпрометировано:

Как нетрудно увидеть, подход, с которым к вопросу читаемости подписываемого подходят компании-производители кошельков, мало что решает, зато добавляет серию дополнительных векторов атаки.

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

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

В результате горячий кошелёк может подсунуть сайнеру любую «интерпретацию», а блокчейн никак не отличит транзакцию, показанную честно, от транзакции, показанной с подменёнными параметрами (например, неправильное число знаков после запятой или «левый» метод контракта).

Критикуешь — предлагай.

Окей.

В экосистеме Polkadot для каждой цепи есть формализованный словарь метаданных, описывающий типы транзакций, их поля, типы данных, параметры активов (включая decimals, идентификаторы ассетов и т.д.).

Из этого словаря собирается Merkle-дерево, а его root-хэш включается в рантайм и становится частью состояния/логики валидации: все узлы сети согласны, что актуальная метадата — именно эта.

Горячий кошелёк, формируя транзакцию для Polkadot-подобной сети, помимо самих байтов транзакции даёт сайнеру меркловские ветки от того самого root-хэша для нужных кусочков словаря (например, «этот assetId — это токен X с N знаками после запятой»).

Аппаратный сайнер:

В Polkadot уже реализован единый Ledger-апп (Unified App) для всех Substrate-сетей: одно приложение на Ledger умеет корректно парсить разные типы транзакций разных цепочек, опираясь на стандартный механизм метадаты и мерклового root.

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

Спасибо за внимание, если знаете еще способы решения этой проблемы, велком в мою телегу.