Разработка MPC-кошелька

Разработка MPC-кошелька

Традиционный криптокошелёк держит приватный ключ в одном месте: на устройстве, в HSM, в облаке. Любое компрометирование этого места = потеря средств. MPC (Multi-Party Computation) решает фундаментальную проблему по-другому: приватный ключ никогда не существует целиком ни в одной точке системы. Вместо этого несколько сторон держат key shares и совместно вычисляют подпись, не раскрывая друг другу своих долей.

Это не мультисиг. В мультисиге подпись транзакции требует M из N подписей, каждая из которых видна on-chain — сеть знает, что используется мультисиг. В MPC финальная подпись выглядит как обычная ECDSA подпись одного ключа. Никакой on-chain overhead, никаких изменений в протоколе. Это критично для: снижения gas costs, privacy (скрывает схему управления ключами), совместимости с любыми chain и dApp.

Математический фундамент

Shamir's Secret Sharing и threshold schemes

Основа MPC-кошельков — threshold signature schemes (TSS). Наиболее используемые: GG18, GG20 (Gennaro-Goldfeder), CGGMP21, и DKLS19.

Shamir's Secret Sharing — базовое понятие, но не сама TSS. В SSS секрет делится на N шардов, M из N достаточно для восстановления. Проблема: восстановление требует собрать шарды в одном месте — уязвимость. TSS устраняет это: подпись вычисляется без сборки ключа.

Threshold ECDSA (используем secp256k1 как в Bitcoin/Ethereum):

Пусть приватный ключ d = d1 + d2 (mod q) для 2-of-2 схемы. Каждая сторона держит d1 и d2. При подписи:

1. Каждая сторона генерирует свой nonce: k1, k2
2. Совместно вычисляют R = (k1 + k2)^(-1) * G (commitment protocol)
3. Каждая сторона вычисляет свою часть s: s1, s2
4. Финальная подпись: s = s1 + s2 (mod q) 
5. Подпись (r, s) — обычная ECDSA подпись

Сложность в шаге 2: прямое вычисление потребует раскрытия k1 или k2. Поэтому используется Oblivious Transfer, Paillier encryption или Curve25519-based протоколы для безопасного вычисления.

Протоколы: GG20 vs CGGMP21

GG20 (Gennaro-Goldfeder 2020) — долгое время стандарт де-факто. Используется в Fireblocks, ZenGo, Coinbase Wallet. Поддерживает threshold t-of-n для произвольных t и n. Требует Paillier encryption для secure multiplication.

Недостатки GG20: сложность реализации, дорогой keygen (O(n²) коммуникаций), уязвимость к «rouge key attack» требует range proofs что увеличивает размер сообщений.

CGGMP21 (Canetti-Gennaro-Goldfeder-Makriyannis-Peled 2021) — текущий state-of-the-art. Исправляет уязвимости GG20, более эффективный signing (меньше раундов коммуникации). Поддерживает identifiable abort — если одна сторона ведёт себя злонамеренно, можно идентифицировать её по криптографическому доказательству.

DKLS19 — альтернатива на основе Oblivious Transfer. Более компактные сообщения, но меньше реализаций в production.

Key refresh

Критически важная операция: периодическое обновление key shares без изменения публичного ключа (а значит, без смены адреса). Если атакующий скомпрометировал один шард, но не успел получить финальную подпись до refresh — компрометация нейтрализована.

Refresh protocol (упрощённо):
1. Каждая сторона генерирует новые random shares: r1, r2, ...rn
2. Суммируют: Σri = 0 (нулевое суммарное изменение)
3. Каждая сторона добавляет свой ri к текущему di
4. Публичный ключ d*G не меняется: Σ(di + ri)*G = d*G + Σri*G = d*G

Рекомендуемая частота refresh: каждые 30-90 дней, или при подозрении на компрометацию любого участника.

Архитектура production MPC-кошелька

Типичная 2-of-3 схема для мобильного кошелька

┌──────────────────────────────────────────────────────┐
│  User Device (Mobile)   │  Company Server  │  Backup  │
│  Share 1 (локально,     │  Share 2         │  Share 3 │
│  зашифрован биометрией) │  (HSM/TEE)       │  (MPC    │
│                         │                  │  backup) │
└──────────────────────────────────────────────────────┘

Signing: Device + Server (2-of-3)
Recovery: Device + Backup или Server + Backup

Пользователь теряет телефон → восстановление через Server + Backup шарды. Сервер взломан → нет шанса без Device или Backup. Это модель ZenGo и аналогичных non-custodial MPC кошельков.

Компоненты системы

Key generation service. Реализует DKG (Distributed Key Generation) протокол между участниками. Результат: каждый участник получает свой share, никто не знает полный ключ. Реализации: tss-lib (Binance, Go), multi-party-ecdsa (ZenGo, Rust), threshold-sig-lib (Fireblocks internal).

// ZenGo's curv + tss-lib пример (Rust)
use curv::elliptic::curves::{Secp256k1, Point, Scalar};
use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2020::party_i::*;

// Phase 1: каждая сторона генерирует commitment
let party1_keys = Keys::create(1);
let (commit1, decom1) = party1_keys.phase1_broadcast_phase3_proof_of_correct_key();

// Phase 2: обмен commitments, вычисление vss
// Phase 3-5: verification и финализация shares
// Результат: party1_keys.u_i — приватный share стороны 1

Signing service. Оркестрирует signing sessions между участниками. Должен поддерживать: concurrent sessions (несколько транзакций параллельно), timeout handling (если участник не отвечает), session ID для корреляции сообщений.

Communication layer. Шифрованный P2P канал между участниками. TLS + дополнительное end-to-end шифрование сообщений протокола. Нельзя использовать незашифрованный канал: промежуточные сообщения содержат частичные значения, которые при накоплении могут утечь share.

HSM/TEE integration. Серверный share хранится в HSM (AWS CloudHSM, Thales) или TEE (Intel SGX, ARM TrustZone). Критично: операции с share выполняются внутри защищённой среды, share никогда не выходит в открытую память. Azure Key Vault Managed HSM и AWS CloudHSM поддерживают custom key operations через PKCS#11 interface.

Протокол восстановления

Важнейший UX-аспект: как пользователь восстанавливает доступ без seed phrase.

Social recovery MPC. Backup share зашифрован ключами доверенных лиц (guardians). Для восстановления нужно согласие M из N guardians. Реализация: backup share шифруется через threshold encryption для guardian set. Guardian может быть: другое устройство пользователя, email сервис (через KMS), trusted friend (через их публичный ключ), recovery service.

KMS-based backup. Backup share зашифрован через пользовательский KMS ключ. Для восстановления: пройти KYC/authentication через KMS provider → расшифровать backup share → выполнить re-sharing с новым device share.

Поддержка chain: multi-curve MPC

Разные блокчейны используют разные эллиптические кривые:

TSS для ed25519 отличается от secp256k1: используется схема на основе Schnorr подписей (FROST protocol — Flexible Round-Optimized Schnorr Threshold). FROST проще в реализации, более эффективен по коммуникации. Для production multi-chain кошелька нужно поддерживать оба.

Hierarchical Deterministic (HD) в MPC контексте. Классический BIP32 нельзя применить напрямую: нет единого seed. Решение: threshold BIP32 — каждая сторона хранит свой share для master private key, child key derivation выполняется через MPC операции или через хранение отдельных shares для каждого derived path (менее эффективно, но проще).

Безопасность и аудит

Attack vectors

Malicious party in signing protocol. Участник может пытаться получить информацию о чужих shares через аномальные сообщения. Защита: range proofs, zero-knowledge доказательства корректности каждого промежуточного значения. CGGMP21 специально разработан с identifiable abort: протокол может доказать какая сторона ведёт себя злонамеренно.

Replay attack на signing sessions. Перехваченные сообщения одной signing session не должны использоваться в другой. Защита: session ID включается в каждое сообщение, сессии одноразовые.

Side-channel через timing. Реализации на Java/Python уязвимы к timing attacks при операциях с большими числами. Production реализации должны использовать constant-time arithmetic (библиотека ct-codecs, Rust subtle crate).

Compromised communication channel. TLS с certificate pinning + дополнительный authenticated encryption на уровне протокола (каждое MPC сообщение подписывается долгосрочным ключом отправителя).

Рекомендации по аудиту

MPC протокол — криптографически сложный компонент. Аудит должен включать:

• Проверку корректности реализации конкретного протокола (GG20/CGGMP21) относительно бумаги
• Анализ side-channel устойчивости
• Fuzz testing signing sessions с аномальными сообщениями
• Verifiable key generation (публичный ключ совпадает с ожидаемым)

Провайдеры для MPC аудита: NCC Group, Kudelski Security, специализируются в cryptographic implementations.

Готовые библиотеки vs custom реализация

Рекомендация: для большинства проектов — интеграция с Web3Auth MPC Core Kit или Fireblocks MPC SDK вместо написания с нуля. Кастомная реализация MPC протокола требует глубокой экспертизы в прикладной криптографии и занимает 6–12 месяцев. Ошибка в MPC реализации = потенциальная утечка приватных ключей пользователей.

Этапы разработки

Минимальный production-ready MPC кошелёк (2-of-2, один chain, базовый recovery) — 4–5 месяцев. Полнофункциональный multi-chain с social recovery и HSM — 8–12 месяцев.