Multisig или MPC: как устроена распределенная подпись и на чем ломаются корпоративные кошельки

Убрать приватный ключ с единственного сервера — только первый шаг. Корпоративному кошельку нужно ответить еще на три вопроса: кто вправе разрешить операцию, что именно он при этом подтверждает и кто может поменять сами правила перевода средств. Multisig и MPC распределяют полномочия на разных уровнях системы. От этого зависит все остальное: где кошелек уязвим, с какими блокчейнами он работает и как выглядит его операционная деятельность.

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

Что именно мы сравниваем

Словом multisig называют разные вещи. Мы рассматриваем протоколы мультиподписи на блокчейне (onchain multisig), основанные либо на смарт-контракте, либо реализованные внутри кода блокчейна. Например, в Bitcoin правила расходования коллективных средств позволяет проверить скрипт внутри сети, а в Ethereum - смарт-контракты. Об этом подробнее мы расскажем немного позже.

MPC (Multi-Party Computation) — это семейство криптографических протоколов, которые позволяют нескольким сторонам вместе что-то вычислить, не показывая друг другу свои частные данные (секретные ключи). Когда говорят об MPC-кошельках, имеют в виду пороговую подпись (threshold signature scheme или TSS): несколько участников коллективно создают подпись, и никто из них не видит чужую долю секретного ключа. Строго говоря, сам по себе MPC шире, чем TSS и применяется не только в «кошельках». В этой статье мы используем слово MPC именно в этом, «кошельковом» смысле.

Мы будем сравнивать два процесса: мультиподпись и ее агрегацию (Multisig) и протокол совместного и безопасного вычисления одной подписи (MPC).

Модель Multisig

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

Блокчейн Bitcoin, поддерживающий протокол мультиподписи, позволяет использовать специальный скрипт коллективных расходов, который проверяет, что подписи настоящие, принадлежат участникам коллектива и что подписей достаточно.

Рассмотрим схему мультиподписи на блокчейне Bitcoin в режиме «2 из 3». Она означает, что коллектив состоит из 3 участников, а для того, чтобы потратить средства, необходимо минимум две подписи. В схеме можно допустить потерю максимум одного секретного ключа участника: оставшиеся два по прежнему могут проводить операции.

В отличие от Bitcoin, блокчейн Ethereum не поддерживает мультиподпись на уровне базового протокола, поэтому для реализации мультиподписей используются смарт-контракты.

Рассмотрим смарт-контракт Safe, который часто используется для контрактных кошельков с мультиподписью. У контрактного кошелька существует: набор владельцев, настраиваемый порог подписи и способы подтверждения. Каждая операция — это конкретная команда: кому, сколько, с какими данными и каким способом ее исполнить. Способов подтверждения два. Первый — обычный вызов метода подписи. Второй делегирование подписи (DELEGATECALL), при котором чужой код исполняется от имени самого кошелька и получает доступ к его внутренним настройкам. Запомним второй: он вернется в истории со взломом Bybit. Для более подробного изучения, предлагаем ознакомиться с Моделью Safe Smart Account. Стоит также отметить, что у контрактного кошелька нет приватного ключа в привычном смысле этого слова. Все решает код контракта и его настройки. Поэтому защищать приходится не только подписи, но и все, чем можно заменить владельцев, порог, подключенные модули или логику кошелька.

В общем смысле мультиподпись обладает несколькими выраженными недостатками:

1. Линейным увеличением размера коллективной подписи с увеличением числа подписантов - каждая “транзакция” с коллективного кошелька это N+1 транзакция в блокчейне (N - требуемое число участников для порога), а значит это в N раз больше расходов на комиссию и ресурсы блокчейна.
2. Необходимы дополнительные проверки целостности и полноты мультиподписи для исключения возможности подмены количества или состава участников. И здесь приходится рассчитывать или на корректность и поддержку реализации со стороны блокчейна или на безопасность и операционную логику используемого смарт-контракта.
3. При изменении состава участника в блокчейне, поддерживающим мультиподпись на уровне протокола, произойдет изменение адреса коллективного кошелька, по сути, это будет новый кошелек без средств.

Модель MPC или распределенное вычисление подписи

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

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

Рассмотрим создание ключа, используя протокол MPC.

Существует два способа генерации:

• С использованием доверителя (trusted dealer key generation)
• Без использования доверителя, распределенная схема (distributed key generation)

Генерация с использованием доверителя является простым алгоритмом. Это значит что в протоколе существует сущность, которая распределяет секретные доли участников. Для разделения общего ключа на доли может использоваться любой доступный алгоритм, например схема разделения ключей Шамира (SSS). После разделения, соответствующие доли направляются участникам протокола. Это приводит нас к рассуждениям о модели доверия и обеспечении безопасности доверителя; ведь в случае его компрометации, злоумышленник способен извлечь общий секретный ключ и украсть средства.

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

Рассмотрим алгоритм коллективной подписи, который может быть использован в протоколах MPC

Также, как и в генерации ключа, существует два способа:

• С использованием доверителя
• Распределенный механизм подписи

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

Коллективная подпись требует отдельного протокола потому что помимо секретного ключа в ней участвует несколько случайных величин. Разберем на примере ECDSA — алгоритма подписи, на котором работают Bitcoin и Ethereum. В его формуле участвуют сразу два секрета: приватный ключ и одноразовое случайное число, которое создается для каждой подписи. Когда оба значения разделены между участниками, подпись нельзя просто собрать из долей, посчитанных по отдельности. Участникам приходится вместе проводить вычисления над данными, которые никто из них не видит целиком.

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

Например, в спецификации пороговой схемы FROST (RFC 9591) сказано: протокол защищает от подделки подписи, но не обещает, что ее удастся получить, если кто-то из участников ведет себя нечестно. Но все же приложениям рекомендуется проверять, что именно их просят подписать. Иначе участник превращается в сервис, который подпишет что угодно. А протокол CMP позволяет определить нечестных участников и прекратить любой протокол будь то подпись, генерация ключей или обновление долей участников.

От чего защищает пороговая подпись, а от чего нет

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

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

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

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

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

Инциденты с Multisig

В приведенных случаях атаковали разные компоненты и уровни системы. Суммы указаны по источникам об инцидентах, без пересчета по текущим курсам.

Parity в июле 2017 года

19 июля 2017 года из трех multisig-кошельков Parity похитили около 153 тысяч ETH, оцененных тогда примерно в 30 млн долларов. Атакующий использовал ошибку повторной инициализации кошелька.

Контракты передавали выполнение общей библиотеке через delegatecall. Этот механизм исполняет код другого контракта в контексте вызывающего: в частности, изменения состояния затрагивают хранилище вызывающего контракта. Функция initWallet, устанавливающая владельцев и порог, оставалась доступна для повторного вызова. Через нее атакующий назначил собственные параметры авторизации, после чего вывел средства. Технический разбор OpenZeppelin.

Parity в ноябре 2017 года

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

По отчету Parity, доступ оказался заблокирован для 587 кошельков с 513 774,16 ETH и дополнительными токенами. Владение ключами зависимых кошельков не позволяло восстановить отсутствующую исполняемую логику. Отчет Parity.

Ronin в марте 2022 года

23 марта 2022 года из моста Ronin вывели 173 600 ETH и 25,5 млн USDC. Мост требовал пять подтверждений из девяти. Инцидент обнаружили 29 марта после обращения пользователя, который не смог вывести средства.

Атакующий получил контроль над четырьмя валидаторами Sky Mavis и возможность получить пятую подпись от Axie DAO. Для этого использовалось разрешение, ранее выданное Sky Mavis (которые уже были скомпрометированы злоумышленником) в связи с повышенной нагрузкой. После прекращения временной потребности разрешение не отозвали. Доступ к связанной инфраструктуре позволил выполнить необходимый порог. Исследование SlowMist.

WazirX в июле 2024 года

18 июля 2024 года WazirX сообщила о хищении активов более чем на 230 млн долларов из multisig-кошелька, работавшего с инфраструктурой Liminal.

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

Radiant Capital в октябре 2024 года

16 октября 2024 года Radiant Capital потеряла около 50 млн долларов. Команда сообщила о компрометации устройств как минимум трех разработчиков, использовавших аппаратные кошельки. Привычный интерфейс отображал ожидаемую операцию, в то время как на подпись поступали вредоносные данные. Захват административных полномочий позволил атаковать средства протокола. Первоначальный post-mortem Radiant.

Bybit в феврале 2025 года

21 февраля 2025 года атака на Ethereum-кошелек Bybit привела к хищению активов примерно на 1,5 млрд долларов. Такая оценка приведена в сообщении ФБР. Сообщение ФБР.

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

Полученные подписи разрешили операцию с DELEGATECALL к вредоносному контракту. Выполнение в контексте кошелька позволило заменить его реализацию. Новая логика предоставила возможность вывода средств без дальнейшего получения обычного набора multisig-подтверждений. Реконструкция Sygnia.

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

Инциденты с MPC

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

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

Самой известной уязвимостью старых MPC решений является уязвимость BitForge.

BitForge

В 2023 году Fireblocks раскрыла уязвимости реализаций пороговой подписи под общим названием BitForge. В случае использования протоколов GG18/GG20 исследователи описали возможность использовать специально сформированные параметры криптосистемы гомоморфного шифрования для извлечения информации о чужом секретном материале. Один из рассмотренных вариантов позволял извлечь ключ за 16 подписаний. Технический отчет GG18/GG20.

В отдельном отчете по протоколу Lindell17 рассматривалась обработка прерванных подписаний: повторные взаимодействия могли становиться каналом утечки. Fireblocks сообщила об исправлениях в Coinbase и Zengo и об отсутствии обнаруженной эксплуатации соответствующих кошельков по результатам их проверок. Технический отчет Lindell17.

THORChain в мае 2026 года

15 мая 2026 года из одного из пяти хранилищ THORChain, которые использовали протокол GG20, похитили примерно 10,7 млн долларов. По отчету проекта, атакующий вошел в сеть как оператор узла за два дня до инцидента, использовал уязвимость BitForge и восстановил полный приватный ключ. После этого он подписывал операции самостоятельно. Отчет THORChain.

Почему MPC подходит для кошельковой инфраструктуры бизнеса

Для корпоративного кошелька необходимо иметь следующие возможности:

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

Pert использует MPC в составе Wallet-as-a-Service — инфраструктуры корпоративных кошельков и работы с цифровыми активами через API или веб-интерфейс. Платформа связывает операции с ролями, политиками и согласованиями, после чего организует подписание и отправку транзакции. Обзор Pert.

Мы в Pert используем протокол распределенных подписей семейства MPC-CMP для блокчейнов на основе ECDSA и FROST для блокчейнов на основе EdDSA. Протоколы семейства MPC-CMP основаны на протоколе CGGMP21, в котором были устранены недостатки предыдущих протоколов, уменьшено количество раундов для операций и добавлен механизм проактивного обновления ключей. Протокол CGGMP21.

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

Корпоративные правила организуются на уровне платформы, без необходимости переносить весь процесс согласования в контракт кошелька. И, глубоко понимая процесс корпоративного управления криптоактивами, мы разделили согласующих и участников подписи. Это не всегда одни и те же люди. Компания может требовать подтверждения от определенных ролей, скажем, от казначея и руководителя направления. Когда подтверждения собраны, сервис запускает подписание по установленной MPC-схеме. Сотрудники приходят и уходят, а аккаунт в блокчейне остается прежним. Политики Pert.

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

В Pert применяется схема пороговой подписи 3 из 3: две доли находятся на стороне Pert, одна — на стороне клиента. Для любой подписи транзакции необходимо участие всех трех. Двух серверных долей недостаточно для самостоятельного формирования подписи без клиентской стороны. Клиентская доля может использоваться через Pert Mobile или участника в виде автоматического подписанта в инфраструктуре клиента. Первый вариант предусматривает пользовательское участие; второй предназначен для автоматизации. Компоненты и криптография Pert

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

Мы предусмотрели прозрачный журнал действий: кем была создана транзакция, кто ее подтвердил, кто ее подписал и какой у нее статус. Эти данные невозможно обнаружить в блокчейне и без них сложно проводить аудиты. Разграничение ролей позволит добавить аудитора в режиме “только для чтения”, что позволяет не останавливать операционные процессы в компании.

Обсудить интеграцию, внедрение и правила подписания можно на демонстрации продукта.