MPC-кошелёк (Multi-Party Computation / MPC-TSS для пороговых подписей) — это кошелёк, где «целый» приватный ключ никогда не собирается на одном устройстве: вместо него несколько сторон держат доли секрета и совместно вычисляют подпись. На цепочке такая подпись выглядит как обычная (одноадресная), поэтому в сетях уровня Ethereum транзакции исходят от единого EOA-адреса без ончейн-мультиподписей.
Это мощная модель (устойчивость к краже одного устройства, прозрачность ончейн), но и особый класс рисков: криптографические протоколы сложны, реализационные ошибки тонкие, а организационная сторона (политики, бэкапы, роли) становится критически важной. Ниже — карта угроз MPC-кошельков и практики, как проектировать их безопасно.
MPC vs мультисиг vs смарт-кошелёк (AA)
| Критерий | MPC / TSS | Ончейн-мультисиг | Смарт-кошелёк (AA) |
|---|---|---|---|
| Что видит блокчейн | Обычная EOA-подпись | M-of-N явно ончейн | Логика в контракте (политики/лимиты) |
| Прозрачность правил | Низкая (политики off-chain) | Высокая (правила на цепи) | Высокая (контракт) |
| Поддержка сетями | Любая сеть с ECDSA/EdDSA | Есть не везде/дорого | Нужна поддержка/газ, но гибко |
| UX и комиссии | Отличные (как EOA) | Дороже/сложней UX | Гибко (батчи, спонсоринг gas) |
| Основные риски | Протокол/реализация, «невидимые» политики, коллюзии долей | Ошибки контракта/потеря множественных ключей | Баги контракта/экосистемные риски |
| Где уместно | Кастоди, трейдинг, биржи, B2B | BTC-L1, консервативные требования аудита | Финтех-продукты, лимиты/гвардии, соц.-восстановление |
Вывод: MPC хорошо решает «прозрачность ончейн» и UX, но правила безопасности живут вне блокчейна — их нельзя проверить снаружи. Это требует повышенной дисциплины DevSecOps и криптоаудита.
Модель угроз MPC-кошелька
* Криптографический уровень. Протокол пороговой ECDSA/EdDSA (MPC-TSS) может содержать ошибки: *nonce reuse*, *rogue-key*, уязвимости в Paillier/обменах. * Реализация/библиотеки. Баги в проверках, генерации случайных чисел, подписании, keygen/resharing. * Организация и операции. Неправильный выбор порога (t,n), невалидные бэкапы долей, коллокация долей в одной зоне отказа, слабые процедуры инцидентов. * Эндпоинты и UX. Заражённые устройства, blind signing, фишинг и злоумышленный фронтенд dApp, подмена «approve unlimited» ([см. транзакцию/кошелёк]). * Юридика и комплаенс. Доли у сторонних кастодианов/провайдеров → риск блокировок/судебных запретов по месту их регистрации (аналогично см. blacklists у стейблкоинов).
Далее — детально по классам.
Криптографические риски и уязвимости TSS
1) Уязвимости протоколов GG18/GG20 (ECDSA). В 2023 исследователи показали уязвимость в широко используемых спецификациях GG18/GG20 (Paillier-основа): злоумышленник может эксфильтровать приватный ключ за 1–2 подписи при недостаточных проверках в протоколе (CVE-2023-33241). Пострадал ряд библиотек и продуктов, потребовались патчи и обновления протокола.
2) TSSHOCK и родственные атаки. В 2023 Verichains представили TSSHOCK — набор практических атак на t-ECDSA реализации (динамики обменов, недостаточные доказательства знаний, проверка диапазонов): возможна полная компрометация ключа после малых серий подписей при злонамеренной стороне. Вывод: неполные проверки и оптимизации в реализациях TSS смертельно опасны.
3) Nonce reuse / плохая энтропия. Классическая проблема ECDSA: повторное (или коррелированное) значение k в двух подписях → арифметически восстанавливается приватный ключ. В MPC это усложняется: k часто генерируется совместно, и недостоверный RNG в одной стороне способен «отравить» процесс; есть реальные кейсы утечек из-за повторного k. Требование: строгое совместное доказуемое RNG, k-confidentiality и аудит.
4) Rogue-key / key-validation. Если участники не доказывают корректность своих публичных вкладов (proof of knowledge / range proofs, корректность Paillier ключей и т.п.), злоумышленник может провести rogue-key атаку, ведущую к компрометации общего секрета. Многие инциденты сводятся к отсутствию или неполному выполнению обязательных доказательств.
5) Уязвимости библиотек и «только на keygen». Открытые реализации (напр., tss-lib) публиковали исправления и отчёты: часть уязвимостей затрагивает только этап генерации ключей (если среди участников присутствовал злонамеренный субъект при keygen), но требует ротации групп и обновления библиотек. Игнорирование подобных бюллетеней оставляет «бомбу замедленного действия».
Реализационные и архитектурные ловушки
Недостаточность «библиотека = безопасность». Даже «правильный» протокол в руках интегратора легко испортить: убрать одну проверку «ради производительности», заменить CSPRNG, забыть timeouts/abort-logic. Большинство практических атак — на стыке теории и кода.
Keygen/reshare как момент максимального риска. Если на этапе keygen/resharing участвовал злонамеренный участник или пропущены доказательства, риск компрометации может стать перманентным. Нужны церемонии генерации, офлайн-каналы, видеопротокол и независимый аудит.
Политики вне блокчейна. Ончейн мы видим «обычную» подпись. Значит, вся безопасная логика (лимиты, whitelist, 2FA, гео/временные правила) выполняется off-chain и может быть обойдена при компрометации N из M долей либо систем оркестрации (policy engine, оркестратор транзакций).
Неочевидная зона отказа. Доли хранятся на «разных» девайсах/у провайдеров — но часто в одном контуре риска (один облачный вендор, один домен администрирования, единый MDM). Это приводит к ложному ощущению «распределённости».
Бэкапы ≠ безопасное восстановление. Хранение копий долей (или «восстановительных бэкапов») у тех же акторов, что и боевые доли, либо в предсказуемых юрисдикциях, нивелирует смысл MPC. Отличайте MPC-восстановление от обычного «шамира»; не путайте с seed-бэкапами (seed-фраза).
Необдуманный выбор порога. Слишком низкий t (например, 2-of-3 в рознице) + слабые разделения ролей → злоумышленнику достаточно двух слабых устройств/аккаунтов. Слишком высокий t усложняет аварийный доступ и операционные процессы.
Смешение потоков подписания. Один и тот же кластер долей подписывает и выплаты, и высокорисковые DeFi-вызовы. При компрометации фронтенда dApp/интеграции злоумышленник проталкивает «approve unlimited», снимая защиту MPC (подписи валидны). Решение: разделяйте кластеры, включайте инспекцию calldata, минимизируйте allowances.
Операционный и юридический риск
Коллюзия и давление на хранителей долей. Если часть долей удерживается внешними компаниями, на них могут воздействовать юридически (subpoena), административно (регулятор), физически (BGP/дата-центр). В ряде кейсов вокруг институциональных MPC-сетапов потери доступа возникали не из-за криптографии, а из-за процессов и бэкапов (см. кейс StakeHound vs Fireblocks: потеря ключевого доступа привела к судебному спору о ~38 178 ETH).
Санкционные/юрисдикционные ограничения. Доли у поставщиков из одной страны → риск «одним приказом» остановить операции. Планируйте юридическое разведение ролей и локаций.
Доступность и DoS. MPC-подписание требует координации нескольких узлов. DDoS/сбой одного узла может «заморозить» выводы. Нужны избыточные участники, независимые каналы связи, офлайн-процедуры аварийных подпечатей.
Эндпоинты, UX и человеческий фактор
Blind signing и обман интерфейса. Если пользователь/оператор не видит декодированный и проверенный calldata, MPC никак не защитит от подписи вредоносной транзакции. Именно поэтому в 2025 году ряд вендоров акцентирует «анти-blind-signing» слои (симуляции, полис-движки, алерты).
Заражение конечных устройств. Мобильные/рабочие станции с долей секрета — мишень малвари. Даже если доля шифруется аппаратно (SE/TEE), злоумышленник может подменить намерение (prompt-injection, overlay, session hijack) и «легально» инициировать подписи.
Социальная инженерия. Подмена адреса, токена, сети; навязывание «approve unlimited»; фальшивые апдейты SDK. MPC не лечит процедурные ошибки и фишинг, он лишь снижает риск кражи ключа как артефакта.
Разбор кейсов и уроки индустрии
GG18/GG20 → эксфильтрация ключа. Уязвимости в спецификациях и имплементациях TSS показали, что «академическая» корректность — не гарантия безопасности продукта. Протоколы нужно жёстко дополнять проверками знаний и диапазонов, а код — аудитить и обновлять.
TSSHOCK → атаки одного участника. Даже 1 злонамеренный участник при неправильных проверках способен вытащить весь секрет за 1–2 подписи. Минимизируйте доверие, включайте доказательства и защиту от повторов/перезапусков этапов.
StakeHound vs Fireblocks → операционные процессы. Судебный спор вокруг утери доступа к 38 178 ETH (2021) иллюстрирует: даже крупные провайдеры/клиенты спотыкаются на бэкапах/процессах, а не на матане. Документируйте и регулярно проверяйте DR-план, роли TA/кастоди/вендоров.
«MPC ≠ серебряная пуля» (оценка экспертов). Исследователи/поставщики мониторинга отмечают: взломы бирж происходят и при MPC, когда компрометируются внутренние системы (оркестрация, CI/CD, IAM). Важно защищать всю траекторию транзакции, а не только криптографию.
Паттерны безопасной архитектуры MPC
Криптография и библиотеки - Используйте протоколы с современными доказательствами против rogue-key и корректности Paillier/обменов; следите за бюллетенями уязвимостей и обновляйте библиотеки (включая tss-lib). - Совместный RNG с верификацией: *commit-reveal*, проверки непредсказуемости, отказ при аномалиях. - Keygen-церемонии: офлайн окружение, видеопротокол, подписанные отчёты, независимые наблюдатели.
Политики и оркестрация - Разделяйте кластеры: выплаты ≠ DeFi. Для высокорисковых вызовов — отдельные лимиты/пороги/кворумы. - Применяйте policy-engine с симуляцией транзакции и декодированием calldata; запрещайте blind signing; проверяйте целевой контракт/функцию/поля. - Вводите мультифактор на уровне людей/устройств (FIDO2, физические токены) и мягкие «ночные»/гео-лимиты.
Инфраструктура - Истинная распределённость: разные облака/AS, независимые домены администрирования, изоляция CI/CD и ключевой плоскости. - DR-план: регулярные учения «потеря доли/вендора», документированные RTO/RPO, тест ротации ключа и resharing без простоя. - Аттестация (TEE/SE) где возможно; но не полагайтесь только на маркетинг TEE — проектируйте крипто-гарантии на протокольном уровне.
Юридика - Разводите хранителей долей по юрисдикциям и правовым субъектам; учитывайте санкционные/регуляторные риски. - Ясная политика апгрейдов: timelock, публичные оповещения, внешние аудиторы.
Пользователи и интерфейсы - Показывайте пользователю читаемое назначение транзакции (декодер), предупреждения по «approve unlimited». - Интегрируйте allow-list адресов/контрактов и «двухконтурную» подачу (черновик → подтверждение). - Обучайте операторов: см. базовая безопасность, приватность.
Чек-лист аудита MPC-кошелька (due diligence)
Протокол и код - Какая версия TSS? Есть ли контрмеры против rogue-key, корректность Paillier/диапазонные доказательства? Патчи по CVE-2023-33241 применены? - Как реализован RNG и совместная генерация k? Как ловятся повторы/корреляции? - Пройден ли внешний аудит/формальная верификация? Какой процесс рассылки security-бюллетеней?
Операции и процессы - Порог t/n, разделение ролей, независимость долей (облака/AS/юрисдикции). - Наличие keygen-церемонии и регулярных reshare-учений. - DR-план (потеря доли/вендора), RTO/RPO документированы и тестировались?
Политики и UX - Есть ли layer для симуляции транзакций и запрет blind signing? Расширяемые правила (лимиты, время, гео, тип функции)? - Разделены ли кластеры на «касса/DeFi»? «Approve unlimited» запрещён политикой по умолчанию? - Логи и оповещения: кто, когда и что подписал? Есть необратимые журналы?
Юридика - Где зарегистрированы стороны, держащие доли? Возможны ли юридические запреты на подпись? - Политика инцидентов/апгрейдов: timelock, уведомления, внешний наблюдатель.
Сравнение моделей хранения/подписания
| Модель | На что похожа для пользователя | Сильные стороны | Уязвимости/риски |
|---|---|---|---|
| MPC / TSS (EOA) | Обычный адрес, «магия внутри» | UX, кросс-чейновость, гибкость порогов | Протокол/реализация; политики off-chain; коллюзия долей |
| Мультисиг ончейн | Видны M-of-N и правила | Прозрачность правил, ончейн-гарантии | Дороже/сложней UX; не везде доступно |
| Смарт-кошелёк (AA) | Контракт со «сторожами» | Лимиты/гвардии/соц-восстановление; спонсоринг газа | Риски контракта/эко-совместимости |
| HSM у кастодиана | «Банк хранения» | Аппаратные корни доверия, зрелые процессы | Централизация; блокировки/юрисдикции |
FAQ
Защитит ли MPC от drain-атаки через «approve unlimited»? Нет. MPC защищает ключ, но не намерение. Если вы подписали «approve unlimited», злоумышленник опустошит баланс через контракт. Нужны политики на calldata/симуляция.
Достаточно ли 2-of-3? Для розницы — часто да; для бизнеса — лучше 3-of-5 и выше, с независимостью долей и разделением ролей.
Нужен ли всё равно бэкап? Да, но корректный: не храните «целый ключ», а стройте восстановление долей (reshare) с иными участниками/юрисдикциями. Проверяйте процедуры.
Можно ли комбинировать MPC и мультисиг? Да: MPC-узел как один из подписантов смарт-кошелька (AA) — для особо критичных хранилищ.
Почему «MPC ≠ серебряная пуля»? Потому что большинство крупных взломов — это IAM/DevOps/оркестрация/UX, а не математика. Стройте защиту сквозь весь стек.